Decizie CNSC 3041/2025

În conformitate cu prevederile art. 14 alin. (2) și ale art. 27 alin. (1) 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, Consiliul adoptă următoarea DECIZIE Nr. 3041/C9/3298 Data: 10.10.2025 Prin contestația înregistrată la Consiliul Național de Soluționare a Contestațiilor cu nr. 58856/25.08.2025, depusă de ALTIMATE SA, cu sediul în Bucureşti, Şoseaua Olteniţei nr. 107A, Corp CI, camera 1613, etaj 6, sector 4, înregistrată la Registrul Comerţului sub nr. J2014014079406, având CUI RO33870323, reprezentată legal prin director general Claudiu Bălan şi convenţional prin STOICA & ASOCIAŢII SCA, cu sediul procesual ales în Bucureşti, str. Dr. N. Staicovici nr. 2, Opera Center II, etaj 2, sector 5, privind procedura de licitație deschisă, organizată în vederea atribuirii contractului de furnizare având ca obiect Sistem de e-ticketing necesar pentru îmbunătățirea transportului public de călători in zona metropolitană Timișoara, cod CPV 34970000-7 Echipament de monitorizare a traficului (Rev.2), de MUNICIPIUL TIMIȘOARA, cu sediul în Timișoara, Bv. C.D.Loga nr. 1, județul Timiș, în calitate de autoritate contractantă, contestatoarea a solicitat: - obligarea autorităţii contractante la adoptarea măsurilor de remediere, prin înlăturarea, modificarea din/în documentaţia de atribuire a cerinţelor/criteriilor nelegale, respectiv restrictive, completarea cu cerinţele necesare, sau, după caz, clarificarea acestora, ţinând seama de toate elementele menţionate în contestaţie; - suspendarea procedurii de atribuire, până la soluţionarea pe fond a contestaţiei. Prin Încheierea nr. 3104/C9/3298/28.08.2025, Consiliul a admis cererea de suspendare a procedurii, formulată de ALTIMATE SA. Pentru aceste motive, în baza legii și a mijloacelor de probă aflate la dosar, CONSILIUL DECIDE: În temeiul art. 26 alin. (2) și (5) 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 Pagina 1 din 2

de lucrări şi concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, pentru considerentele evocate în motivarea prezentei, admite, în parte, contestația formulată de ALTIMATE SA, în contradictoriu cu MUNICIPIUL, în privința criticilor nr. IV, V, VI, VII.2, VII.3, VII.4 și VII 5 din cuprinsul contestației. Obligă autoritatea contractantă, în termen de 20 zile de la data primirii

prezentei

decizii,

să

modifice/completeze/remedieze documentația de atribuire, conform celor reținute în considerente, și să aducă la cunoștința tuturor operatorilor economici interesați măsurile adoptate, prin postarea acestora în SEAP, cu stabilirea unei noi date de depunere a ofertelor, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. Totodată, în măsura în care informațiile referitoare la elementele pentru care Consiliul a dispus remedierile mai sus amintite, se regăsesc și în cadrul altor documente din conținutul documentației de autoritatea contractantă va proceda în consecință și va corela informațiile în concordanță cu remedierile dispuse. În temeiul art. 26 alin. (6) din Legea nr. 101/2016 pentru considerentele evocate în motivarea prezentei, respinge, ca nefondate restul solicitărilor din cadrul celorlalte critici din contestația formulată de ALTIMATE SA, în contradictoriu cu MUNICIPIUL TIMIȘOARA. Prezenta decizie este obligatorie pentru părțile cauzei potrivit dispozițiilor art. 28 alin. (1) din Legea nr. 101/2016, cu modificările și completările ulterioare. Împotriva prezentei decizii se poate formula plângere, în termen de 10 zile de la comunicare pentru părțile cauzei, respectiv de la data luării la cunoștință de către alte persoane vătămate, în temeiul art. 29 din Legea nr. 101/2016. PREȘEDINTE, MEMBRU, MEMBRU, Redactată în 4 exemplare originale, conține 85 pagini. Pagina 2 din 2

În conformitate cu prevederile art. 14 alin. (2) și ale art. 27 alin. (1) 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, Consiliul adoptă următoarea DECIZIE Nr. ... Prin contestația înregistrată la Consiliul Național de Soluționare a Contestațiilor cu nr. .., depusă de .. SA, cu sediul în ., înregistrată la Registrul Comerţului sub nr. ., reprezentată legal prin director general . şi convenţional prin .., cu sediul procesual ales în ., privind procedura de licitație deschisă, organizată în vederea atribuirii contractului de furnizare având ca obiect ., cod CPV 34970000-7 Echipament de monitorizare a traficului (Rev.2), de .., cu sediul în ., în calitate de autoritate contractantă, contestatoarea a solicitat: - obligarea autorităţii contractante la adoptarea măsurilor de remediere, prin înlăturarea, modificarea din/în documentaţia de atribuire a cerinţelor/criteriilor nelegale, respectiv restrictive, completarea cu cerinţele necesare, sau, după caz, clarificarea acestora, ţinând seama de toate elementele menţionate în contestaţie; - suspendarea procedurii de atribuire, până la soluţionarea pe fond a contestaţiei. Prin Încheierea nr. ., Consiliul a admis cererea de suspendare a procedurii, formulată de .. SA. CONSILIUL NAȚIONAL DE SOLUȚIONARE A CONTESTAȚIILOR, asupra cauzei de față, constată următoarele: Consiliul a fost legal sesizat și este competent, potrivit dispozițiilor art. 12 alin. (1) din Legea nr. 101/2016, să soluționeze contestația de față, prin care ofertantul .. SA critică unele prevederi ale documentaţiei de atribuire, solicitând cele precizate în partea introductivă a deciziei. I. Contestatoarea susține că documentaţia de atribuire cuprinde o serie de neconformităţi ce trebuie remediate, respectiv: (i) Obiectul achiziţiei nu este în corespondenţă cu Codul CPV principal care îl descrie cel mai exact (Secţiunea II din contestaţie) (ii) Cerinţele prevăzute la Secţiunea 4.2.7. Alte cerinţe din Caietul de sarcini sunt disproporţionate şi restrictive (Secţiunea III din contestaţie) Pagina 1 din 95

(iii) Cerinţa stabilită prin caietul de sarcini ca sistemul nou de e- ticketing să ofere integrare cu platformele FIWARE şi SynchroniCity determină restrângerea artificială a concurenţei (Secţiunea IV din contestaţie) (iv) Prin documentaţia de atribuire se solicită un număr semnificativ de integrări cu aplicaţii software şi echipamente externe existente, precum şi furnizarea unor funcţionalităţi viitoare și integrări cu sisteme "viitoare", fără furnizarea documentaţiei tehnice de integrare sau a oricăror alte detalii tehnice (Secţiunea V din contestaţie) (v) Documentaţia de atribuire cuprinde cerinţe tehnice care nu au legătură cu obiectul contractului de achiziţie publică, care excedă obiectul acestuia sau care sunt disproporţionate prin raportare la obiectivele acestuia, (Secţiunea VI din contestaţie) (vi) Mai multe menţiuni din documentaţia de atribuire nu asigură o informare completă, corectă şi precisă cu privire la cerinţele achiziţiei şi modul de desfăşurare a procedurii de atribuire. În special documentaţia de atribuire nu descrie în mod clar modalitatea de îndeplinire a criteriilor de selecţie privind experienţa similară şi modalitatea în care va fi acordat punctajul aferent fiecărui Subfactor de evaluare în contextul criteriului de atribuire cel mai bun raport calitate preţ. (Secţiunea VII din contestaţie) II. Obiectul achiziţiei nu este în corespondenţă cu Codul CPV principal care îl descrie cel mai exact Autoarea contestației arată că, așa cum rezultă din Secţiunea nr. II din anunţul de participare şi din fişa de date a procedurii de atribuire, obiectul achiziţiei constă în furnizarea unui "Sistem de e-ticketing necesar pentru îmbunătăţirea transportului public de călători în zona metropolitană Timişoara", care să respecte cerinţele indicate în caietul de sarcini. Prin urmare, obiectul şi scopul principal al achiziţiei este înlocuirea şi modernizarea sistemului de taxare/validare pentru transportul public din zona metropolitană Timişoara, ci nu de echipamente de monitorizare a acestuia. Atât anunţul de participare, cât şi fişa de date şi caietul de sarcini, menţionează drept Cod CPV principal - 34970000-7 Echipament de monitorizare a traficului, cu toate că, în opinia petentei, o mai exactă corespondenţă dintre obiectul achiziţiei şi Codul CPV principal ar fi asigurată prin raportare la Codul CPV 30123100-8 Maşini de validare a biletelor (Rev.2). Invocând prevederile art. 83 alin. (1) şi 3 din Legea nr. 98/2016 și art. 16 alin. (2) din HG nr. 395/2016, contestatoarea solicită Consiliului să pună în vedere autorităţii contractante să adopte măsuri de remediere în sensul înlocuirii codului CPV principal indicat în documentaţia de atribuire potrivit menţiunilor de mai sus, pentru a permite informarea corectă a tuturor operatorilor economici care utilizează criteriul codului CPV în căutarea și identificarea procedurilor la care intenţionează să participe. Pagina 2 din 95

III. Eliminarea cerinţelor disproporţionate şi restrictive prevăzute la Secţiunea 4.2.7. Alte cerinţe din caietul de sarcini III.1. Cu privire la Subsecţiunea 4.2.7.1 "Inception Report" și "Analiza-Proiectare" Autoarea contestației arată că în cadrul Subsecţiunii 4.2.7.1 "Inception Report" si "Analiza-Proiectare" din caietul de sarcini (p. 29- 30) se menţionează următoarele cerinţe disproporţionate care au ca efect o restrângere artificială a concurenţei: Având în vedere complexitatea proiectului, multitudinea de integrări și cerinţe, ofertantul va trebui să realizeze la început "Inception Report" și "Analiza-Proiectare" și să prezinte rezultatele pentru realizarea celei mai bune soluții și a unei oferte competitive și bine fundamentată, inclusiv tipurile de training necesare. [...] Toate funcţionalităţile din acest caiet de sarcini se vor demonstra de către ofertanţi la o probă practică, care va face parte din etapa evaluării tehnice a ofertelor, la invitaţia autorităţii contractante. În consecinţă, prin documentaţia de atribuire, autoritatea contractantă solicită operatorilor economici participanţi ca, în cadrul propunerilor tehnice să integreze: (i) pe de o parte, realizarea prealabilă a rapoartelor "Inception Report" și "Analiza-Proiectare" şi (ii) pe de altă parte, o probă practică/demo/sesiune demonstrativă, care va viza toate funcţionalităţile indicate în caietul de sarcini. În continuare, petenta detaliaază motivele pentru care cele două cerinţe încalcă principiului proporţionalităţii şi imperativele legate de nerestricţionatei abuzivă a concurenţei. III.1.1 Cu privire la realizarea celor două rapoarte: "Inception Report" şi "Analiza-Proiectare" Astfel cum rezultă din dispoziţiile caietului de sarcini, scopul acestor rapoarte este de a "descrie/documenta modalitatea de integrare între sisteme precum și cu sistemele externe solicitate". Contestatoarea solicită Consiliului să constata că o asemenea cerinţă este excesivă prin raportare la etapa de elaborare a ofertelor, în condiţiile în care aceste rapoarte presupun o înţelegere aprofundată a tuturor sistemelor, aplicaţiilor și echipamentelor existente, a interfeţelor şi a modului în care acestea schimbă date cu sistemul ofertat în cadrul prezentului proiect. Pentru o descriere corespunzătoare a modalităţii de integrare între sisteme, respectiv cu sistemele externe, este absolut necesar accesul la documentaţia tehnică completă, la echipamente şi la factorii de decizie, care se obţine doar după atribuirea contractului, către ofertantul desemnat câştigător. În etapa de formulare a propunerilor tehnice, ofertanţii nu au acces la informaţiile detaliate despre sistemele cu care trebuie să se realizeze integrarea, împrejurare confirmată chiar de menţiunile din caietul de sarcini (Secţiunea 5.4.6., pag. 45): "Sistemul ERP al STPT este ASSIS iar detaliile cu privire la modul de integrare cu acesta vor fi furnizate câştigătorului licitaţiei". Pagina 3 din 95

În acest context, existenţa acestei cerinţe în cadrul documentaţiei de atribuire încalcă principiile proporţionalităţii şi tratamentului egal, care stau la baza atribuirii contractelor de achiziţie publică, astfel cum sunt prevăzute de art. 2 alin. (2) din Legea nr. 98/2016. În continuare, invocă dispoziţiile art. 50 alin. (1) și (2) şi 155 alin. (1), (2) și (6) din Legea nr. 98/2016, precum și considerentul nr. 74 din preambulul Directivei nr. 24/2014 privind achiziţiile publice, și susține că solicitarea adresată operatorilor economici, încă din etapa de elaborare a ofertei, de a descrie şi documenta în cele două rapoarte "modalitatea de integrare intre sisteme precum și cu sistemele externe solicitate" este vădit disproporţionată, în condiţiile în care o asemenea cerinţă nu poate fi îndeplinită fără acces la informaţiile detaliate despre sistemele cu care trebuie să se realizeze integrarea. Mai mult de atât, existenţa acestei cerinţe poate împiedica accesul egal la procedura de atribuire şi are ca efect introducerea unor obstacole nejustificate faţă de asigurarea unei concurenţe efective între operatorii economici, întrucât poate avantaja un operator economic care are deja acces privilegiat la sistemele existente. Pentru aceste motive, solicită eliminarea cerinţei de includere în ofertă a celor două rapoarte: "Inception Report" și "Analiza-Proiectare". III.1.2. Cu privire la solicitarea de probe practice/sesiuni demonstrative/demo-uri Cu titlu prealabil, autoarea contestației menţionează că proba practică (identificată şi sub denumirea de "demo" sau "Sesiunea demonstrativă" în cadrul contractelor pentru achiziţia de sisteme IT) este un instrument care permite unui operator economic să prezinte clientului său părţi ale produsului IT pe care îl vinde sau versiunea integrală a produsului respectiv. Cu toate acestea, având în vedere principiul proporţionalităţii precum şi imperativul instituit de legislaţia achiziţiilor publice ca cerinţele/specificaţiile tehnice să permită tuturor operatorilor economici accesul egal la procedura de atribuire şi să nu aibă ca efect introducerea unor obstacole nejustificate faţă de asigurarea unei concurenţe efective, solicitarea unei sesiuni demonstrative în cadrul contractelor pentru achiziţia de sisteme IT ar trebui să fie o soluţie excepţională. Într-adevăr, atât timp cât există metode alternative de verificare a capacităţii tehnice a unui ofertant (criterii de calificare referitoare la experienţa similară prin care se pot solicita referinţe, recomandări, documentaţii şi print-sreen-uri, URL-uri etc.) şi de evaluare a capacităţii/abordării tehnice (cerinţe pentru propunerea tehnică constând în asigurarea unui anumit nivel de pregătire şi experienţă profesională experţilor implicaţi sau în impunerea unei anumite abordări tehnice, factori de evaluare care să puncteze suplimentar experţii mai bine pregătiţi sau abordările tehnice de înaltă calitate), o asemenea cerinţă Pagina 4 din 95

suplimentară poate avea ca efect încălcarea prevederilor legale legate de proporţionalitate. Prin urmare, autoritatea contractantă ar fi trebuit să justifice solicitarea unei sesiuni demonstrative din perspectiva oportunităţii şi necesităţii în ciuda disponibilităţii instrumentelor amintite în paragraful anterior, inclusiv prin raportare la oportunitatea resurselor de timp şi de bani care ar urma să fie consumate de către ofertanţi şi impactul probabil al acestora asupra nivelului de concurenţă. Cu toate acestea, autoritatea contractantă nu a oferit nicio justificare pentru care a inclus această cerinţă suplimentară, cu încălcarea principiilor transparenţei şi proporţionalităţii. De altfel, inclusiv formularea din cadrul cerinţei „toate funcţionalităţile" este vagă, extrem de generală şi neclară, fiind susceptibilă să creeze arbitrar şi abuzuri cu ocazia evaluării, inclusiv o posibilă excludere abuzivă din procedura de atribuire. În continuare, contestatoarea prezintă principalele motive pentru care se impune excluderea cerinţei privind proba practică. În primul rând, pregătirea unei sesiuni demonstrative este de natură a aduce costuri semnificative suplimentare ofertanţilor, acestea crescând cu cât cerinţele pentru sesiunea demonstrativă vizează aplicaţii software care nu sunt disponibile deja pe piaţă sau funcţionalităţi care nu există deja la aplicaţii disponibile pe piaţă (aplicaţia respectivă nu este de tip .. - Commercial Of The Shelf, cum este cazul celor mai multe componente din Sistemul de e-ticketing care face obiectul prezentei achiziţii). Aceste costuri nu pot fi recuperate decât de ofertantul câştigător. Impunerea unor astfel de costuri ofertanţilor este împotriva tendinţei ultimilor ani de la nivel european şi naţional de a simplifica procesul de achiziţie publică şi de a reduce costurile administrative legate de acesta (deci inclusiv legate de ofertare şi verificarea/evaluarea ofertelor) atât de partea ofertanţilor cât şi de partea autorităţii contractante. De asemenea, pregătirea unei sesiuni demonstrative necesită timp suplimentar pentru etapa de ofertare faţă de termenele obişnuite minime pentru depunerea ofertelor aşa cum sunt reglementate - în mod evident, solicitarea unor sesiuni demonstrative pentru produse ..personalizat sau la comandă conduce la prelungirea procesului de achiziţie publică. În al doilea rând, solicitarea unei sesiuni demonstrative pentru aplicaţii de tip .. personalizat sau la comandă (chiar şi pentru părţi din acestea) echivalează cu solicitarea către ofertanţi de a executa total sau parţial viitorul contract de manieră anticipată la nivelul ofertei. O astfel de situaţie este excesivă şi contra înţelesului comun care poate fi atribuit diferenţei dintre, de o parte, procesul de ofertare şi ce înseamnă propunerea tehnică şi, pe de altă parte, procesul de execuţie a contractului ca atare. Într-adevăr, caietul de sarcini include în mod expres activităţi de dezvoltare şi integrare, care prin natura lor nu pot fi Pagina 5 din 95

demonstrate în cadrul unei sesiuni de probă practică la momentul ofertării. În al treilea rând, această cerinţă este de natură a limita în mod direct numărul operatorilor economici interesaţi de transmiterea unei oferte la cei care sunt dispuşi să îşi asume, în plus faţă de costurile administrative obişnuite ale ofertării, şi pe cele medii spre mari ale pregătirii unei aplicaţii software sau funcţionalităţi la o aplicaţie software de la "0" sau la cei care s-au pregătit anticipat pentru aplicaţia software respectivă, cu încălcarea prevederilor art. 50 şi 155 alin. (6) din Legea nr. 98/2016, anterior citate (având ca efect restrângerea nejustificată a concurenţei). În plus, în opinia petentei, cerinţa încalcă în mod direct principiul nediscriminării/tratamentului egal, întrucât poate favoriza în mod nejustificat anumiţi operatori economici, respectiv pe aceia care au deja produse implementate în mod identic. În al patrulea rând, legislaţia în domeniul achiziţiilor publice impune ca verificarea capacităţii tehnice ale unui ofertant de a realiza viitorul contract să se facă prin cerinţe de calificare legate de acest aspect rezultând că nu se poate invoca de către autoritatea contractantă nevoia de a verifica suplimentar capacitatea tehnică a unui ofertant prin alte cerinţe care nu sunt cerinţe de calificare. În plus, autoritatea contractantă nu are dreptul de a utiliza factori de evaluare care să conducă la o libertate de apreciere nelimitată şi trebuie să asigure o concurenţă reală între operatorii economici. În al cincilea rând, contestatoarea precizează că toate aceste motive care impun autorităţii contractante să nu solicite în mod abuziv o sesiune demonstrativă/probă practică, au fost reţinute de către ANAP în cadrul Îndrumării privind adecvarea solicitărilor de sesiuni demonstrative/demo-uri ca parte din propunerea tehnică în cadrul contractelor pentru achiziţia de sisteme IT (Anexa nr. 4), citând din această Îndrumare. Or, astfel cum a precizat şi cum rezultă din documentaţia de atribuire, Sistemul de e-ticketing care face obiectul procedurii de atribuire cuprinde, în cea mai mare parte, exact astfel de componente de software personalizat, acesta nefiind un produs IT de tip ... De altfel, chiar şi în cazul în care Sistemul ofertat ar fi fost un produs IT de tip .., autoritatea contractantă avea oricum obligaţia de justifica alegerea includerii acestei cerinţe, prin raportare la costurile suportate de ofertanţi. În susținerea celor precizate, invocă din Îndrumarea ANAP. Pentru aceste motive, solicită Consiliului să oblige autoritatea contractantă la adoptarea de măsuri de remediere în sensul excluderii cerinţei referitoare la proba practică (demo). III.2. Cu privire la Subsecţiunea 4.2.7.2 prin care se solicită documente justificative pentru experţii non-cheie Pagina 6 din 95

Contestatoarea arată că în cadrul Subsecţiunii 4.2.7.2 Necesar personal Non Cheie din caietul de sarcini, există cerinţa de a prezenta în cadrul ofertei obligatoriu „câte o persoană desemnată din fiecare personal non cheie, care să îndeplinească rolurile de Senior HW Engineer / Echivalent si Senior SW Engineer / Echivalent". De asemenea, cu privire la aceşti experţi non-cheie, caietul de sarcini prevede necesitatea de a se depune documente justificative care atestă experienţa anterioară a acestora în proiecte relevante. Cerinţa de a depune documente justificative privind experienţa relevantă a experţilor non-cheie este excesivă prin raportare la principiul proporţionalităţii şi la prevederile art. 155 alin. (6) din Legea nr. 98/2016, coroborat cu art. 20 alin. (10) din HG nr. 395/2016, precum şi la Instrucţiunea ANAP nr. 1/2017. De altfel, contestatoarea precizează că solicitarea de documente justificative în acest context reprezintă una dintre cele mai frecvente neconformităţi identificate în cadrul documentaţiilor de atribuire de către ANAP, cu ocazia controlului ex-ante, efectuat în conformitate cu Ordonanţa de urgenţă nr. 98/2017. În continuare, invocă din Materialul publicat de ANAP la data de 05.10.2021, care cuprinde cele mai frecvente neconformităţi identificate în cadrul documentaţiilor de atribuire aferente contractelor de servicii, precum şi măsurile de remediere, înscrise în avizele conform condiţionate emise, în activitatea de control ex-ante. Pentru aceste motive, contestatoarea apreciază că se impune eliminarea cerinţei de a prezenta documentele justificative care dovedesc experienţa experţilor non-cheie în cadrul propunerii tehnice şi alinierea cu îndrumarea ANAP. IV. Cerinţa stabilită prin caietul de sarcini ca sistemul nou de e- ticketing să ofere integrare cu platformele FIWARE şi SynchroniCity determină restrângerea artificială a concurenţei Autoarea contestației arată că în conformitate cu Secţiunea II.1.4) din anunţul de participare şi fişa de date, precum şi cu Secţiunea 2.1 Obiectivul Achiziţiei din caietul de sarcini, sistemul de e-ticketing care face obiectul procedurii de atribuire trebuie: - să ofere integrare cu platforma FIWARE; - să ofere integrare cu platforma europeana SynchroniCity. De asemenea, potrivit Secţiunii 7.4 Integrarea cu sisteme externe din caietul de sarcini - 7.4.1 Fiware Se doreşte integrarea cu platforma open source FIWARE Mai multe detalii la adresa: .. - 7.4.2 SynchroniCity Se doreşte integrarea cu platforma SunchroniCity Mai multe detalii la adresa: .. Astfel cum a arătat deja, din art. 50 şi 155 din Legea nr. 98/2016, interpretate în lumina Directivei nr. 24/2014 privind achiziţiile publice, specificaţiile tehnice trebuie să permită tuturor operatorilor economici Pagina 7 din 95

accesul egal la procedura de atribuire şi nu trebuie să aibă ca efect introducerea unor obstacole nejustificate faţă de asigurarea unei concurenţe efective între operatorii economici. În acelaşi sens, prezintă o deosebită relevanţă prevederile art. 156 din Legea nr. 98/2016. Prin urmare, specificaţiile tehnice ar trebui elaborate în aşa fel încât să se evite restrângerea în mod artificial a concurenţei prin cerinţe care favorizează un anumit operator economic. În special, legislaţia naţională şi europeană interzice desemnarea în documentaţia de atribuire a unui producător/produs/soluţie determinată, cu eliminarea oricăror posibile soluţii echivalente. Într-adevăr, faptul de a nu adăuga menţiunea "sau echivalent" după desemnarea, în caietul de sarcini, a unei tehnologii determinate cu care trebuie să se asigure interoperabilitatea poate să descurajeze operatorii economici care utilizează sisteme similare acestui produs să participe la procedura de achiziţie şi, deci, distorsionarea concurenţei. În acest context legislativ, impunerea operatorilor economici să utilizeze exclusiv tehnologiile FIWARE şi SynchroniCity, respectiv ca Arhitectura sistemului să fie "construită în jurul standardelor FIWARE și SynchroniCity", cu eliminarea oricăror soluţii echivalente bazate şi pe alte standarde deschise, este de natură să restrângă în mod artificial concurenţa şi poate avea ca efect favorizarea sau eliminarea anumitor operatori economici, cu încălcarea prevederilor anterior citate. În primul rând, astfel cum rezultă din prevederile art. 156 alin. (2) din Legea nr. 98/2016, referirea la o tehnologie concretă cu care trebuie să se asigure integrarea este interzisă, singura derogare fiind instituită de alin. (3) din acelaşi text, care prevede că o asemenea trimitere "este permisă în situaţii excepţionale, în cazul în care nu este posibilă o descriere suficient de precisă şi de inteligibilă a obiectului contractului". Dar chiar şi în această situaţie absolut excepţională, nu este în niciun caz posibilă limitarea la o singură tehnologie concretă (cum sunt platformele FI WARE şi SynchroniCity), fiind obligatoriu să se menţioneze în documentaţia de atribuire posibilitatea furnizării de soluţii echivalente. De asemenea, din dispoziţiile alin. (4) ale aceluiaşi text de lege rezultă că orice operator economic trebuie să aibă posibilitatea să dovedească că "soluţiile propuse îndeplinesc într-un mod echivalent cerinţele definite prin specificaţiile tehnice". În al doilea rând, FIWARE şi SynchroniCity nu au caracter de standard obligatoriu, astfel încât evaluarea propunerilor tehnice prin raportare la compatibilitatea cu o singură categorie de tehnologii nestandardizate generează riscul unui rezultat arbitrar şi neconformitate tehnică. Astfel: - FIWARE este o platformă open source concepută pentru a facilita dezvoltarea aplicaţiilor inteligente în diverse sectoare, dar nu este impusă prin legislaţie naţională sau europeană ca standard obligatoriu pentru sisteme de e-ticketing sau pentru oraşe inteligente. Pagina 8 din 95

- SynchroniCity este un cadru conceptual, un set de bune practici şi puncte de interoperabilitate rezultat dintr-un proiect Horizon 2020, dar fără statut de standard tehnic obligatoriu sau de platformă funcţională recunoscută oficial. De asemenea, SynchroniCity este un proiect de cercetare, nu un produs comercial matur, cu suport şi SLA (Service Level Agreement) garantat. Dependența exclusivă de aceste platforme creează riscuri de continuitate şi mentenanţă pentru autoritatea contractantă, contrar principiilor de neutralitate tehnologică şi de evitare a dependenţei de un singur furnizor. În al treilea rând, autoritatea contractantă nu a prezentat o justificare clară din care să rezulte că utilizarea exclusivă a celor două tehnologii, fără nicio posibilă soluţie echivalentă, ar genera beneficii directe pentru cetăţeni sau pentru funcţionalitatea sistemului de e- ticketing. Documentaţia de atribuire nu cuprinde nicio justificare privind necesitatea şi proporţionalitatea exclusivităţii acestor standarde, mai ales în condiţiile în care zona metropolitană Timişoara nu este parte activă în reţelele FIWARE/SynchroniCity. Astfel, nu există nicio justificare pentru care să fie eliminate soluţiile echivalente bazate şi pe alte standarde deschise, care să prezinte aceleaşi avantaje şi specificaţii tehnice (platformă open source, cu API Standardizate, care să permită gestionarea şi actualizarea informaţiilor contextuale în timp real). În al patrulea rând, chiar în cadrul caietului de sarcini, Secţiunea 4.2.5 Standarde şi normative de respectat, este solicitată în mod expres respectarea altor standarde pentru integrare (transfer și schimb de date), respectiv: Modelul de referinţă european pentru datele din transportul public, formatul de transfer si schimb de date - Transmodel, împreună cu toate modelele acoperite: •NeTEx •SIRI •OpRa •OJP •GTFS și GTFS-RT https://transmodel-cen.eu/ În al cincilea rând, din Secţiunea 14 Factori de evaluare din caietul de sarcini, pct. 2.1 rezultă că se va acorda punctajul maxim din perspectiva acestui criteriu de evaluare doar dacă propunerea tehnică include integrarea standardelor FIWARE şi SynchroniCity în centrul arhitecturii, favorizând astfel în mod nejustificat ofertanţii deja integraţi în aceste sisteme şi distorsionând concurenţa. În al şaselea rând, contestatoarea precizează că aceleaşi concluzii au mai fost reţinute în jurisprudenţa CNSC, respectiv decizia nr. .. Pagina 9 din 95

Prin urmare, petenta solicită obligarea autorității contractante la adoptarea de măsuri de remediere pentru a permite furnizarea unor soluţii echivalente cu privire la integrarea sistemului de e-ticketing. V. Prin documentaţia de atribuire se solicită un număr semnificativ de integrări cu aplicaţii software şi echipamente externe existente, precum şi furnizarea unor funcţionalităţi viitoare și integrări cu sisteme "viitoare", fără furnizarea documentaţiei tehnice de integrare sau a oricăror alte detalii tehnice Autoarea contestației arată că, pe de o parte, prin documentaţia de atribuire se solicită o serie de integrări cu aplicaţii software şi echipamente externe existente (software-ul instalat pe echipamentele existente şi cu software-ul de management a traficului existent): - În cadrul Secţiunii 4.2 Descrierea Sistemului din caietul de sarcini - Subsecţiunea 4.2.1 Integrarea funcţionalităţi lor sistemului de e- Ticketing în soluţiile cloud scalabile - pct. 2. Componenta de e- Monitorizare și Informare călători (e-MIC) - Analiza şi controlul traficului se menţionează: Analiza şi controlul traficului prin monitorizarea şi controlul traficului (integrare cu ultimul upgrade la platforma Omnia/Swarco); - În cadrul Secţiunii 5 Componenta de taxare/procesare de plăţi (e- TAX) din caietul de sarcini - Subjecţiunea 5.1 Descrierea generală a Platformei se menţionează: Având în vedere vehiculele noi din flota STPT recepţionate în ultimii 5 ani (40 tramvaie Bozankaya, 44 autobuze electrice Karsan) și cele 33 troleibuze și 30 autobuze electrice 10m în curs de achiziţie precum și dotarea acestora cu Calculatoare de bord, validatoare și senzori de numărare, Platforma de e-Taxare (e-TAX) va integra echipamentele (Calculatoare de bord, validatoare EMV și senzori de numărare) de pe aceste vehicule; - În cadrul Secţiunii 6 Platforma e-Monitorizare și Informare călători (e-MIC) din caietul de sarcini se precizează că: Această platformă va furniza cel puţin funcţionalitatea existentă pe aplicaţia ... De asemenea, în cadrul Subsecţiunii 6.1 Arhitectura Platformei e-Monitorizare și Informare se precizează următoarele cerinţe de integrare: - 6.1.2 Modul Echipamente îmbarcate - 6.1.2.1 MCM/OBC: Cerinţe tehnice minime: Interconectare cu sistemul OMNIA aflat la centrul de trafic al Primăriei Timişoara și posibilitate de extindere pentru sisteme dedicate managementului de trafic; - 6.1.4 Modulul Publicitate (MP) - Modulul de Publicitate va oferi posibilitatea de conectare SECURIZA T din backoffice către TOATE sistemele existente de publicitate din mijloacele de transport în comun, a panourilor de informare călători din staţii, sau a Display- urilor LCD de informare în staţii ce fac parte din reţeaua .. Însă, astfel cum a arătat şi în secţiunile anterioare, din prevederile art. 50 alin. (2) coroborat cu art. 155 alin. (6) din Legea nr. 98/2016, rezultă că: - cerințele tehnice trebuie să permită tuturor operatorilor economici accesul egal la procedura de atribuire; - în cazul în care achiziţia ori elemente ale acesteia sunt concepute sau structurate cu scopul de a favoriza ori dezavantaja în mod nejustificat anumiţi operatori economici, se va considera că există o restrângere artificială a concurenţei. Pagina 10 din 95

Astfel, cerinţele anterior menţionate prin care se solicită integrări cu aplicaţii software şi echipamente externe existente determină o restrângere a concurenţei şi nu asigură tratamentul egal, în condiţiile în care furnizorii soluţiilor (companiile ..SRL, ..SRL) au un avantaj semnificativ, fiind singurii care cunosc toate detaliile tehnice ale aplicaţiilor cu care se solicită integrarea (specificaţii tehnice detaliate de produs hardware și software, documentaţii de integrare, protocoale de comunicaţii, etc.). Niciuna dintre informaţiile necesare pentru integrare nu sunt publice, fiecare producător protejându-și produsele și aplicaţiile software. În susţinerea neconformităţii tuturor acestor cerinţe de integrare, contestatoarea face trimitere şi la considerentul (74) al Directivei 2014/24. Pe de altă parte, arată că prin documentaţia de atribuire se solicită o serie de integrări cu sisteme viitoare, precum şi integrarea în cadrul ofertei a unor funcţionalităţi viitoare, fără a fi prezentate detalii tehnice suficiente (acces la documentaţia de integrare a sistemului, standardele de comunicare), care să permită ofertanţilor să evalueze fezabilitatea tehnică a integrării sau evaluarea costurilor reale ce urmează să fie suportate. - Astfel, în cadrul Secţiunii 5 Componenta de taxare/procesare de plăţi (e-TAX) din caietul de sarcini se menţionează că: Ofertantul declarat câştigător va asuma dezvoltarea sistemului de e-TAX care face obiectul prezentei achiziţii și în viitor, fără costuri suplimentare pentru Autoritatea Contractantă, oferind soluţii de API care să permită cel puţin următoarele integrări, fără a se limita la acestea: - integrarea de noi echipamente hardware, inclusiv definirea unor cerinţe de integrabilitate pentru acestea; - integrarea cu alte sisteme de ticketing de tip ABT, în spiritul interoperabilităţii între sisteme. - În cadrul Subsecţiunii 5.4 Zona de Front Office - 5.4.5 Platforma web și aplicaţia mobilă se menţionează că: Se va ține cont de dezvoltări ulterioare și de interconectări cu sistemele de biciclete, „ride sharing" și alte modalităţi de călătorie ce pot fi utilizate, gen trenuri regionale, etc. Cerinţele impuse privind integrarea cu sistemele viitoare împiedică în mod absolut ofertanţii să evalueze fezabilitatea tehnică precum şi riscurilor tehnice ce pot apărea, ori să estimeze calculul costurilor şi durata de implementare. Din punct de vedere tehnic, o integrare a unui sistem/aplicaţie software presupune în mod necesar: - Acces

la

documentaţia

de

integrare

a sistemului/aplicatiei/echipamentului existent, respectiv descrierea modului în care acesta acceptă sau transmite date; Pagina 11 din 95

- Standardele de comunicare, respectiv cunoaşterea protocoalelor, formatelor de date sau interfeţelor care sunt folosite (de ex. XML, JSON, API); - Date de test - pentru a verifica dacă informaţia circulă corect între sisteme; - Eventuale restricţii sau licenţe, respectiv dacă sistemul existent aparţine unui alt furnizor, pentru a cunoaşte dacă este permis accesul şi în ce condiţii. În absenţa oricărui acces la aceste informaţii/date la momentul elaborării ofertei, operatorul economic se află în imposibilitatea de a: - evalua fezabilitatea tehnică a integrării - ofertanţii nu pot ști dacă integrarea este posibilă sau nu; - nu se pot estima costurile reale - lipsa informaţiilor face imposibilă întocmirea unei oferte financiare corecte şi complete. Petenta menţionează că integrarea a două sisteme implică costuri financiare resurse umane şi de timp semnificative, care trebuie evaluate corect încă din etapa elaborării ofertelor în cadrul procedurii de atribuire. Suplimentar, autoarea contestației susține că şi în cazul integrării cu sisteme viitoare se creează un avantaj nejustificat pentru operatorii care au deja acces la aceste informaţii (..SRL, ..SRL), cu încălcarea principiului tratamentului egal. Pentru toate aceste motive, solicită obligarea autorităţii contractante la adoptarea de măsuri de remediere prin eliminarea din documentaţie a oricăror precizări cu privire la integrări/dezvoltări ulterioare cu sisteme/aplicaţii software/echipamente pentru care autoritatea contractantă nu este în măsura să pună la dispoziţia tuturor ofertanţilor informaţiile tehnice relevante. De asemenea, solicită Consiliului să dispună adoptarea de măsuri de remediere pentru asigurarea informării integrale a tuturor participanţilor la procedura de atribuire, atât cu privire la aplicaţiile/sistemele echipamentele existente pentru care se solicită integrarea, cât şi pentru cele viitoare cu privire la care autoritatea contractantă este în măsură să pună la dispoziţie informaţiile tehnice relevante. Pentru aplicaţiile software cu care se solicită integrarea, solicită obligarea autorității contractante la punerea la dispoziţia tuturor operatorilor economici, de la momentul întocmirii ofertei, a următoarelor informaţii/date: - funcţionalităţile tehnice detaliate ale acestor aplicaţii software; - manuale de utilizator, manuale de administrare; - documentaţia de integrare; - protocoale/ standarde de comunicaţie acceptate; - API-uri (Application Programming Interface); Pagina 12 din 95

- descrierea modalităţilor de realizare a schimbului de informaţii între aplicaţiile existente şi sistemele solicitate prin caietul de sarcini sau orice alte documente relevante sau necesare integrării. Pentru fiecare din echipamentele cu care se solicită integrarea (panouri din reţea .., validatoare, computere de bord, sisteme de numărare), solicită obligarea autorității contractante la punerea la dispoziţia tuturor operatorilor economici, de la momentul întocmirii ofertei, a cel puţin următoarelor informaţii: - codurile produselor şi denumirea producătorului; - versiunile de Firmware; - specificaţii tehnice detaliate de produs hardware şi software; - manuale de utilizator, descrieri şi schiţe; - manuale de administrare; - documentaţii de integrare; - protocoale de comunicaţii utilizate de echipament pentru schimbul de date cu aplicaţii terţe; - datele necesare pentru realizarea schimbului de informaţii între echipamentele solicitate în prezenta procedură cu echipamentele existente/în curs de implementare sau orice alte documente relevante sau necesare integrării. VI. Documentaţia de atribuire cuprinde cerinţe tehnice care nu au legătură cu obiectul contractului de achiziţie publică, care excedă obiectul acestuia sau care sunt disproporţionate prin raportare la obiectivele acestuia Invocând prevederile art. 155 alin. (1) şi (2) din Legea nr. 98/2016, petenta precizează că în cadrul caietului de sarcini sunt prevăzute o serie de specificaţii tehnice care: (i) fie nu au nicio legătură cu obiectul contractului de achiziţie publică, (ii) fie exced obiectul acestuia (iii) fie sunt disproporţionate prin raportare la obiectivele acestuia, determinând limitarea accesul egal al operatorilor economici la procedura de atribuire. Astfel, în primul rând, în Secţiunea 5 Componenta de taxare/procesare de plăţi (e-TAX) din caietul de sarcini - Subsecţiunea 5.2 Cardurile contactless, se menţionează următoarele specificaţii fizice şi chimice ale Suportului de card: dimensiuni card: conform ISO 7810ID-1 temperatura de funcţionare: -25°C +70°C testare conform cu standardul ISO 10373-6 Cu toate acestea, proiectul care face obiectul procedurii de atribuire nu cuprinde furnizarea de carduri, astfel încât solicită obligarea autorității contractante la eliminarea acestei cerinţe. În al doilea rând, arată că în cadrul aceleiaşi Subsecţiuni din caietul de sarcini se menţionează: "Având în vedere faptul NXP deţine drepturile exclusive asupra tehnologiei MIFARE, și existența a foarte multe clone nelicentiate și care conţin chiar instrucţiuni de tip "backdoor", ofertantul trebuie să aibă certificat acordat de Arsenal Testhouse GmbH sau altă instituţie independenta conform ISO 17025, acceptată de către NXP". Pagina 13 din 95

Astfel, se solicită prin documentaţia de atribuire ca ofertantul să fie certificat de laboratoare independente cum ar fi Arsenal Testhouse GmbH, cu toate că exclusiv producătorii de carduri dotate cu card NXP pot fi certificaţi de astfel de laboratoare. În consecinţă, în opinia petentei, această cerinţă se impune a fi eliminată din documentaţia de atribuire, întrucât: - pe de o parte, furnizarea de carduri cu cip NXP nu face obiectul prezentei proceduri de achiziţie publică; - pe de altă parte, cerinţa limitează în mod nejustificat accesul egal al operatorilor economici care nu sunt şi producători de carduri la procedura de atribuire. În al treilea rând, în Secţiunea 8 Cloud Hosting - Subsecţiunea 8.3 Minimul de resurse cloud - 8.3.2 Cerinţe la nivel de DataCenter se menţionează următoarea cerinţă: Ofertanţii vor transmite o descriere detaliată a locaţiei datacenterului pentru serviciile de Cloud (inclusiv adresa) și a facilităţilor disponibile care să corespundă cel puţin elementelor solicitate. Pentru fiecare cerinţă ofertantul va detalia producătorul, tipul și modelul echipamentelor utilizate, numărul și amplasamentul acestora. Curentul electric consumat de echipamentele necesare va fi inclus în oferta financiară transmisă. Astfel, contestatoarea solicită Consiliului să oblige autoritatea contractantă să excludă această cerinţă din documentaţia de atribuire, întrucât: - Pe de o parte, prin caietul de sarcini se solicită furnizarea unor servicii de găzduire şi stocare a aplicaţiilor software furnizate într-un Cloud. Autoritatea cere informaţii care nu sunt accesibile niciunui ofertant rezonabil, întrucât furnizorii de servicii Cloud nu dezvăluie niciodată astfel de detalii tehnice (producător, tip, model, număr, amplasament echipamente). Astfel, cerinţa limitează în mod nejustificat accesul egal al operatorilor economici la procedura de atribuire; Pe de altă parte, cerinţa nu este proporţională prin raportare la obiectivul achiziţiei. În condiţiile în care sunt solicitate servicii de tip Cloud, accentul trebuie să fie pus pe caracteristicile serviciului (securitate, disponibilitate, certificări), nu pe inventarul fizic al echipamentelor, acestea fiind lipsite de orice relevanţă. Mai multe menţiuni din documentaţia de atribuire nu asigură o informare completă, corectă şi precisă cu privire la cerinţele achiziţiei şi modul de desfăşurare a procedurii de atribuire. Invocând dispoziţiile art. 3 lit. z), 154 alin. (1) din Legea nr. 98/201 şi art. 20 alin. (2) din HG nr. 395/2016, petenta susține că în cadrul documentaţiei de atribuire se regăsesc o serie de informaţii referitoare la cerinţele şi criteriile de atribuire/selecţie neclare şi netransparente sau incomplete care se impun a fi rectificate, astfel cum va arăta în continuare. VII.1. Prin documentaţia de atribuire nu este asigurată o informare completă, corectă şi precisă/clară a operatorilor economici privind modalitatea în care va fi acordat punctajul pentru fiecare subfactor Pagina 14 din 95

Contestatoarea arată că în conformitate cu Secţiunea II.2.5 din anunţul de participare şi din fişa de date, precum şi cu Secţiunea 14 Factori de evaluare din caietul de sarcini, autoritatea contractantă va aplica criteriul de atribuire cel mai bun raport calitate-preţ, in conformitate cu prevederile art. 187 alin. (3) lit. a) din Legea nr. 98/2016). De asemenea, s-a stabilit că "Cel mai bun raport calitate-preţ" se va determina prin utilizarea următorilor factori de evaluare - Preţul ofertei Pondere: 25% - Garanţia sistemului Pondere: 20% - Project Manager / echivalent Pondere: 10% - System Architect / echivalent Pondere: 10% - Metodologia de livrare a sistemului Pondere: 25% - Senior Integration Engineer / echivalent Pondere: 10% Cu privire la Factorul "Metodologia de livrare a sistemului" în documentaţia de atribuire se menţionează: Se evaluează claritatea şi deschiderea arhitecturii propuse, integrarea standardelor relevante, diferenţierea între componentele reutilizabile şi cele dezvoltate la comandă, nivelul de securitate conform cerinţelor actuale, precum şi coerenţa planului de implementare şi livrare. Acordarea punctajului aferent privind Metodologia de livrare a sistemului (25 pct.) este divizat în patru Subfactori: - Subfactor 1: Arhitectura sistemului construită în jurul standardelor FIWARE și SynchroniCity cu o listă de API-uri pentru fiecare componentă din secţiunea de Arhitectura din anexa 3 la caietul de sarcini (10 puncte); - Subfactor 2: Componente .. (Commercial Off-The-Shelf) vs dezvoltate pentru PMT (7 puncte); - Subfactor 3: Arhitectura de securitate (Zero Trust + NIS2) (5 puncte); - Subfactor 4: Plan de implementare şi termene (3 puncte); În funcţie de algoritmul de acordare a punctajului, pentru fiecare Subfactor se poate obţine fie un punctaj maxim, fie unul intermediar, fie punctajul minim (0). Cu toate acestea, în ceea ce priveşte Factorul "Metodologia de livrare a sistemului", prin documentaţia de atribuire nu este asigurată o informare completă, corectă şi precisă/clară a operatorilor economici privind modalitatea în care va fi acordat punctajul pentru fiecare Subfactor. Cu titlu de exemplu, în privinţa primului Subfactor, în documentaţia de atribuire nu este descris prin raportare la ce repere/criterii obiective şi clare va aprecia Comisia de evaluare că ofertantul a furnizat (i) Arhitectură completă, clară, coerent structurată si documentată - 10 pct., (ii) Arhitectura parţial completă, dar insuficient detaliată - 4 pct. (iii) Arhitectura este vagă, lipsesc elemente esenţiale - 0 pct. Pentru a înlătura posibilitatea unor aprecieri subiective şi pentru a asigura transparenţa şi corecta efectuare a evaluării ofertelor prin Pagina 15 din 95

raportare la criteriile de atribuire, solicită Consiliului obligarea autoritatea contractantă la adoptarea măsurilor de remediere prin care să definească în mod clar criteriile şi modalitatea de analiză pentru acordarea punctajului aferent fiecăruia dintre cele patru criterii care compun Factorul Metodologia de livrare a sistemului, prin precizarea baremului de acordare a punctajului în mod transparent și cuantificabil. În cazul în care criteriile (Subfactorii) şi modalitatea de analiză nu pot fi definite în mod clar, trasabil şi transparent, solicită Consiliului să dispună eliminarea acestora din documentaţia de atribuire. VII.2 Cu privire la experienţa similară, menţiunile prin care se detaliază modalitatea de îndeplinire nu sunt clare Contestatoarea arată că în cadrul Secţiunii III.1.3.a) din fişa de date privind Capacitatea tehnică şi/sau profesională se menţionează că se va verifica experienţa similară, modalitatea de îndeplinire fiind următoarea: Ofertanţii vor face dovada că în ultimii trei ani, raportat la termenul limită de depunere a ofertelor, au implementat, respectiv au pus în funcţiune cel puţin un sistem de e-ticketing destinat transportului public/privat, la nivelul a minim un contract - maxim trei contracte, care a/au inclus următoarele caracteristici minime: - sistemul a fost destinat unui operator economic/autoritate contractantă care deserveşte cel puţin 1.000.000 tranzacţii pe an, și minim 100.000 conturi în sistem, respectiv un volum de trafic comparabil ca ordin de mărime cu cel estimat în prezentul proiect; - soluţia implementată a acoperit cel puţin următoarele componente: • emiterea şi gestionarea digitală a sistemelor de acces • validarea electronică • sistem backend pentru administrare, monitorizare şi raportare. Toate acestea sunt necesare să se fi realizat prin integrarea cu cel puţin două metode de plată moderne (ex: card bancar, aplicaţie mobilă, terminal POS). Formularea din documentaţia de atribuire privind modalitatea de îndeplinire a criteriului de selecţie este neclară, întrucât nu rezultă dacă îndeplinirea caracteristicilor minime indicate trebuie să existe la nivelul fiecărui contract depus (se pot depune doar contracte care întrunesc toate caracteristicile descrise) sau este permis cumul dintre mai multe contracte (cel mult trei) pentru a dovedi îndeplinirea tuturor caracteristicilor minime. De asemenea, nu este clar dacă, în ceea ce priveşte cea de a doua caracteristică menţionată, toate cele trei componente pe care le cuprinde (emiterea şi gestionarea digitală a sistemelor de acces, validarea electronică, sistem backend pentru administrare, monitorizare şi raportare) trebuie să fie întrunite în cadrul unui singur contract, sau se poate aplica cumulul între mai multe contracte (cel mult trei) pentru a dovedi îndeplinirea acestei caracteristici. Pentru aceste motive, solicită obligarea autorității contractante la dispunerea de măsuri de remediere prin care să clarifice criteriul de selecţie menţionat. VII.3. Integrarea cu sistemul de facturare Contestatoarea arată că în Subsecţiunea 5.4.6 Sistemul de facturare (interconectare cu sistemul ERP propriu), caietul de sarcini Pagina 16 din 95

prevede că: "Sistemul de facturare trebuie să gestioneze procesul de facturare a produselor tarifare şi al altor produse vândute de către Operator. Soluţia trebuie să permită emiterea facturilor, atât pentru persoane fizice, cât şi pentru persoane juridice". Prin raportare la această formulare, solicită obligarea autorității contractante la confirmarea că integrarea cu sistemul e-Factura se realizează de către ERP-ul existent. Se presupune că această integrare este deja realizată, întrucât Beneficiarul emite facturi şi în prezent, din sistemul existent de ERP, ci nu din aplicaţia de taxare e-ticketing. VII.4. Caietul de sarcini nu menţionează în mod clar un număr de SMS-uri de verificare ce trebuie avute în vedere de către toţi ofertanţii pe durata de garanţie a sistemului În cadrul Subecţiunii 5.4.5.2 din caietul de sarcini - Sistemul de Gateway SMS pentru toate tranzacţiile care necesită 2FA/MFA se menţionează că: Pentru toate tranzacţiile care necesită 2FA/MFA, se va utiliza un Gateway SMS. Acesta va fi inclus în preţul ofertei pentru toată perioada de garanţie. De pe el se vor transmite SMS- uri de verificare 2FA/MFA. Gateway-ul va fi de tip PERSONALIZAT și dedicat (nu va fi shared cu alte firme/aplicaţii). Toate costurile ocazionate de folosirea lui, vor fi achitate de către ofertant. Nu se acceptă costuri suplimentare generate de depăşirea numărului de sms-uri din ofertă. Prin această cerinţă se solicită includerea în ofertă a unor costuri ce nu pot fi cuantificate, întrucât nu este menţionată o limită maximă privind numărul de SMS-uri de verificare ce trebuie avute în vedere de către toti ofertanţii pe durata de garanţie a sistemului. Astfel, nu sunt menţionate toate informaţiile necesare pentru a asigura operatorilor economici o informare completă, corectă şi precisă cu privire la cerinţele achiziţiei. În consecinţă, solicită obligarea autorității contractante la precizarea în mod clar în cadrul caietului de sarcini a unui număr de SMS-uri de verificare ce trebuie avute în vedere de către toţi ofertanţii pe durata de garanţie a sistemului. VII.5. Caietul de sarcini nu menţionează toate informaţiile necesare pentru a asigura operatorilor economici o informare completă şi precisă cu privire la cerinţele tehnice pe care trebuie să le respecte Panourile de informare călători Astfel, petenta arată că în cadrul caietului de sarcini este menţionată cerinţa de a furniza şi instala un număr de 110 de Panouri de informare în staţiile de călători. La Subsecţiunea 6.1.3 Modulul de Informare Călători Staţii se precizează cerinţele tehnice pe care trebuie să le respecte Panourile de informare călători: Principalele caracteristici tehnice ale Panoului de informare călători sunt următoarele: • Panourile vor fi cu 2,3,4 şi 5 rânduri. Prin rânduri se înţelege un singur display cu afişare diferite mărimi de caractere; • Culoarea LED-urilor: multicolor, intensitatea luminoasă minim 7000 nits • Unghiul vizibilitate: minimi 10x50 grade; • Posibilitate comunicaţie mobilă si fixa; • Tensiunea de alimentare: 230V/50Hz, din reţeaua publică de electricitate; • Carcasa metalică rezistentă la vandalism şi intemperii; Pagina 17 din 95

• Mentenanţă firmware de la distanţă. În cadrul caietului se sarcini nu sunt menţionate toate informaţiile necesare pentru a asigura operatorilor economici o informare completă şi precisă cu privire la cerinţele tehnice pe care trebuie să le respecte Panourile de informare călători, întrucât: - nu se menţionează câte din cele 110 panouri trebuie să aibă 2 rânduri şi câte trebuie să aibă 3, 4 sau 5, diferenţele de cost între aceste tipuri de panouri fiind semnificative (putând fi chiar triple); - nu se precizează pe ce structură metalică se vor monta aceste panouri (existentă sau viitoare), dacă structura de susţinere trebuie sau nu inclusă în preţul ofertei. - documentaţia de atribuire nu include autorizaţii de construire pentru amplasarea unor eventuale structuri metalice noi şi nici detalii tehnice (planşe) pentru situaţia în care panourile se instalează pe structuri existente (stâlpi, adăpost staţie transport etc). - nu se menţionează în sarcina cui intră lucrările civile (canalizaţie, tuburi, cabluri etc) necesare asigurării alimentării cu energie electrică a acestor panouri. Pentru aceste motive, solicită obligarea autorității contractante la completarea documentaţiei de atribuire cu toate elementele lipsă indicate. Prin adresa nr. ./01.09.2025, înregistrată la Consiliu sub nr. 60862/02.09.2025, autoritatea contractantă a formulat punct de vedere cu privire la contestația depusă de .. SA. Înainte de a răspunde punctual criticilor formulate, autoritatea solicită Consiliului să observe că analiza contestaţiei relevă un aspect esenţial: în afara punctului VI, care priveşte specificaţii tehnice referitoare la carduri (aspect colateral), toate celelalte critici formulate de contestatoare vizează exclusiv cerinţe care au ca scop asigurarea interoperabilităţii, prevenirea dependenţei tehnologice („vendor lock-in"), promovarea standardelor deschise şi evitarea creării de sisteme paralele. Or, aceste principii nu reprezintă simple opţiuni strategice ale autorităţii contractante, ci constituie obligaţii legale şi obiective strategice consacrate: - la nivel european, prin Regulamentul (UE) 2024/903 - Interoperable Europe Act şi Programul „Europa Digitală", care impun statelor membre să adopte soluţii interoperabile şi reutilizabile; - la nivel naţional, prin Legea nr. 242/2022 privind schimbul de date între sisteme informatice şi crearea Platformei Naţionale de Interoperabilitate (PNI), care consacră principiul „o singură dată" şi obligă autorităţile să evite barierele tehnologice şi duplicarea sistemelor; - prin H.G. nr. 908/2017 pentru aprobarea Cadrului Naţional de Interoperabilitate, care stabileşte cerinţe obligatorii pentru integrarea şi interoperabilitatea sistemelor informatice publice. Pagina 18 din 95

În acest context, criticile formulate nu urmăresc corectarea unor presupuse neclarităţi sau disproporţionalităţi, ci tind să împiedice integrarea cu sistemele existente şi să menţină soluţii proprietare, contrar cadrului normativ european şi naţional. Cerinţele contestate sunt, dimpotrivă, menite să asigure conformitatea legală, protejarea investiţiilor publice şi crearea unui ecosistem digital coerent, deschis şi sustenabil. Prin urmare, respinge aceste obiectii ca nefondate şi le va demonta în detaliu în secţiunile următoare, prin argumente tehnice şi juridice. Cu privire la solicitarea contestatoarei privind obligarea autorităţii contractante la dispunerea unor măsuri de remediere - constând în eliminarea, modificarea, completarea sau, după caz, clarificarea cerinţelor/criteriilor pretins nelegale ori restrictive din documentaţia de atribuire – achizitoarea formulează următoarele observaţii: Referitor la punctul II din contestaţie, Obiectul achiziţiei nu este în corespondenţă cu codul CPV principal ales (punctele 4 - 8 din contestaţie): 1. Caracterul complex şi integrat al achiziţiei Contrar afirmaţiei contestatoarei potrivit căreia obiectul achiziţiei ar fi limitat la „maşini de validare a biletelor", documentaţia de atribuire, în special caietul de sarcini, descrie un sistem informatic complex - o platformă digitală integrată de mobilitate urbană, care include următoarele componente şi funcţionalităţi: - subsisteme de ticketing şi validare a biletelor pentru transportul public; - integrare cu ecranele digitale din staţii şi vehicule; - sistem digital de publicitate în vehicule şi staţii; - integrare cu platforma de management al traficului OMNIA/SWARCO; - funcţionalităţi avansate de tip router/planner pentru călătorii; - tarifare diferenţiată pentru diverse categorii de utilizatori (elevi, studenţi, pensionari); - mecanisme de subvenţionare a diverselor politici publice (transport, evenimente culturale, încălzire centralizată etc.); - back-office cu funcţii de business intelligence şi instrumente de raportare pentru operatorul de transport şi autoritatea contractantă; - interoperabilitate şi integrare cu servicii externe (Google Maps, Waze, aplicaţii smart city) prin standardul european FIWARE. Această configuraţie depăşeşte cu mult simpla furnizare de echipamente de validare, proiectul vizând o soluţie tehnologică avansată de management şi monitorizare a mobilităţii metropolitane. De altfel, utilizarea termenului ”e-ticketing" în titlul proiectului reflectă cerinţele de cofinanţare prin PNRR. 2. Codul CPV trebuie să reflecte scopul principal, nu componentele individuale. Pagina 19 din 95

Invocând prevederile art. 16 alin. (2) din HG nr. 395/2016, autoritatea precizează că, în această procedură, scopul principal nu este achiziţia de validatoare, ci implementarea unui sistem integrat de management al mobilităţii urbane şi al transportului public, cu funcţionalităţi extinse de planificare, analiză, control şi interoperabilitate. Prin urmare, alegerea codului 34970000-7 - Echipament de monitorizare a traficului este pe deplin justificată, acesta reflectând fidel scopul complex şi integrat al achiziţiei. 3. Utilizarea codurilor CPV secundare - reflectarea componentelor specifice Pentru o reflectare corectă a tuturor componentelor sistemului, autoritatea contractantă menționează că a avut în vedere şi coduri CPV secundare, inclusiv cel invocat de contestatoare: 30123100-8 - Maşini de validare a biletelor. Totuşi, acest cod vizează o componentă hardware limitată dintr-un sistem IT mai amplu şi, prin urmare, nu putea fi selectat ca CPV principal, în lipsa unei corespondenţe cu obiectul general al contractului. Reamintește că validatoarele sunt doar una dintre multiplele funcţionalităţi finanţate şi implementate. 4. Transparenţă şi nediscriminare - accesul operatorilor economici nu a fost restricţionat Procedura a fost publicată în SEAP şi, conform normelor aplicabile, a fost vizibilă la nivel naţional şi european. În ceea ce priveşte impactul codului CPV asupra participării: - Titlul şi descrierea procedurii sunt clare şi reflectă corect obiectul achiziţiei („Sistem de e-ticketing pentru transport public metropolitan"); - Complexitatea proiectului, natura finanţării şi conţinutul caietului de sarcini asigură vizibilitate maximă pentru toţi operatorii relevanţi; - Alegerea codului CPV principal nu a limitat accesul real al pieţei, deoarece operatorii specializaţi în sisteme de ticketing, mobilitate urbană, soluţii IT şi echipamente de transport au putut identifica şi accesa procedura. De asemenea, utilizarea codurilor CPV secundare a contribuit la asigurarea transparenţei şi a unei descrieri complete a achiziţiei. În concluzie, alegerea codului CPV principal 34970000-7 - Echipament de monitorizare a traficului este conformă cu dispoziţiile legale aplicabile şi reflectă scopul real şi integrat al contractului. Codul propus de contestatoare este, cel mult, aplicabil ca cod secundar, având în vedere caracterul limitat şi auxiliar al componentelor de validare în structura generală a proiectului. Cu privire la punctul III din contestaţie: Eliminarea cerinţelor disproporţionate și restrictive prevăzute la Secţiunea 4.2.7. Alte cerinţe din Caietul de sarcini: Pagina 20 din 95

III.1. Cu privire la Subsectiunea 4.2.7.1 - „Inception Report" si „Analiză - Proiectare" III.1.1. Rapoartele tehnice solicitate în etapa de ofertare (punctele 12 - 21 din contestaţie) În ceea ce privește susținerea contestatoarea că solicitarea elaborării rapoartelor „Inception Report" şi „Analiză-Proiectare" este disproporţionată şi are ca efect restrângerea artificială a concurenței, autoritatea precizează că solicitarea acestor rapoarte în etapa de ofertare este justificată de natura complexă a proiectului şi urmăreşte evaluarea capacităţii metodologice a ofertantului de a propune o soluţie coerentă de integrare a sistemelor solicitate. Aceste documente: - asigură comparabilitatea ofertelor, prin impunerea unei structuri unitare şi evitarea abordărilor arbitrare; - reprezintă o practică uzuală în proiectele IT complexe, în special atunci când sunt implicate tehnologii consacrate (ex: Mifare, NFC, QR, FIWARE, ERP); - permite autorităţii contractante să evalueze modul în care ofertanţii îşi fundamentează planificarea şi alocarea resurselor în mod realist şi coerent; - nu presupun accesul complet la informaţii detaliate, ci doar capacitatea de a propune o arhitectură şi o metodologie iniţială, pe baza cerinţelor generale furnizate în documentaţie; - reflectă o practică deja validată în cadrul altor proiecte similare derulate de Primăria Municipiului Timişoara, cu rezultate pozitive (ex: portal unic, GIS, automatizare fluxuri interne). În concluzie, solicitarea acestor rapoarte este proporţională, fundamentată tehnic şi legal, şi nu restricţionează accesul operatorilor economici cu experienţă relevantă. III.1.2. Sesiunile demonstrative /probe practice (punctele 22 - 37 din contestaţie) Referitor la susținerea contestatoarei că proba practică este excesivă, costisitoare şi restrânge competiţia, achizitoarea precizează că solicitarea unei demonstraţii practice este pe deplin justificată de complexitatea tehnică şi valoarea ridicată a contractului, care implică: - dezvoltarea de componente software personalizate; - integrarea cu infrastructura existentă (OMNIA/SWARCO, ecrane, semafoare etc.); - interoperabilitate cu aplicaţii şi servicii smart city, inclusiv conform standardului FIWARE. Proba demo: - permite evaluarea capacităţii reale de implementare a soluţiei ofertate; - reduce riscul atribuirii unui contract neimplementabil, contribuind la protejarea fondurilor publice; Pagina 21 din 95

- nu restrânge competiţia, întrucât se aplică în mod egal tuturor ofertanţilor, care sunt evaluaţi pe baza aceloraşi cerinţe funcţionale; - este proporţională cu miza proiectului, iar eventualele costuri de pregătire a unei prezentări tehnice sunt inerente participării la o procedură de achiziţie cu grad ridicat de dificultate tehnică. Prin urmare, solicitarea probei demonstrative este justificată, transparentă şi nediscriminatorie şi ţine cont de concluziile şi recomandările ANAP din Îndrumarea privind adecvarea solicitărilor de sesiuni demonstrative /demo-uri ca parte din propunerea tehnică în cadrul contractelor pentru achiziţia de sisteme IT. III.2. Cu privire la solicitarea documentelor justificative pentru experţii non-cheie (punctele 38 - 43 din contestaţie) În ceea ce privește opinia contestatoarei că solicitarea de documente justificative privind experienta relevanta a experţilor non- cheie este excesivă prin raportare la principiul proportionalității, autoritatea susține că, în contextul unui contract care implică dezvoltare IT, integrare de sisteme şi configurare complexă de echipamente, rolul experţilor tehnici non-cheie este esenţial. Prin urmare: - solicitarea unor documente justificative care să ateste experienta asimilată în cadrul unor proiecte similare, are ca scop verificarea realităţii şi calificării personalului tehnic propus; - consideră că această cerinţă nu încalcă principiul proporţionalității, având în vedere complexitatea şi riscurile asociate implementării; - cerinţa contribuie la asigurarea unui control minim asupra resurselor critice, prevenind declararea unor experţi fictivi sau insuficient calificaţi. În concluzie, solicitarea documentelor justificative privind experienta experţilor non-cheie este proporţională, adecvată şi necesară pentru buna implementare a contractului şi continuitatea serviciilor publice. În concluzie, cerinţele prevăzute la secţiunea 4.2.7 din caietul de sarcini sunt legale, proporţionale şi adecvate scopului achiziţiei, reflectând atât complexitatea proiectului, cât şi nevoia de transparenţă, comparabilitate şi siguranţă în implementare. Acestea nu restrâng participarea operatorilor economici, ci garantează selectarea unei soluţii fezabile, funcţionale şi sustenabile, în interesul autorităţii contractante şi al beneficiarilor finali ai sistemului. Referitor la punctul IV din contestaţie: Cerinţa stabilită prin Caietul de sarcini ca sistemul nou de e-ticketing să ofere integrare cu platformele FIWARE și SynchroniCity determină restrângerea artificială a concurenței (punctele 44 - 59 din contestaţie): 1. Context european şi justificare tehnologică Pagina 22 din 95

Autoritatea menționează că FIWARE şi SynchroniCity sunt iniţiative europene dezvoltate cu finanţare publică, având drept scop promovarea interoperabilităţii şi reutilizării soluţiilor digitale în mediul urban. • FIWARE este o platformă open-source creată în cadrul programului Future Internet Public-Private Partnership (FI-PPP) al Comisiei Europene, beneficiind de o finanţare de peste 300 milioane euro. În prezent, este gestionată de organizaţia non-profit FIWARE Foundation e.V., cu sediul în Berlin. Platforma este utilizată de peste 400 oraşe la nivel global, cu o comunitate extinsă de dezvoltatori şi peste 600 de componente reutilizabile. - Detalii: https://www.fiware.org/about-us/ - Cod sursă şi API: https://www.fiware.org/catalogue/ • SynchroniCity, proiect derulat în cadrul Horizon 2020, a implementat în doar 6 luni peste 50 de servicii IoT în 21 de oraşe europene şi este parte a reţelei Open & Agile Smart Cities (OASC), care numără peste 150 de oraşe membre. Acest proiect a stabilit cadrul tehnic pentru mecanismele minime de interoperabilitate (MIMs), recunoscute ca bune practici la nivel european. -

Detalii:

https://synchronicity-iot.eu/knowledge/technical- framework/ Ambele platforme sunt liber accesibile, deschise şi non-restrictive din punct de vedere comercial, fără costuri de licenţiere şi cu suport comunitar activ. 2. Motivaţia introducerii cerinţei în documentaţia de atribuire Integrarea cu FIWARE şi SynchroniCity nu urmăreşte restrângerea concurenţei, ci: • asigurarea interoperabilităţii între sistemul nou de e-ticketing şi soluţiile digitale deja utilizate de autoritatea contractantă (proiectul de video-analytics dezvoltat în FIWARE); • evitarea dependenţei faţă de un singur furnizor („vendor lock- in"), prin utilizarea unor standarde europene deschise; • crearea unui ecosistem urban digital unitar, bazat pe reutilizarea componentelor open-source şi pe integrarea cu alte servicii publice (trafic, parcări, mobilitate, GIS etc.). 3. Neutralitate tehnologică şi deschidere către soluţii echivalente: Cerinţa de integrare nu vizează un produs comercial anume, ci respectarea unor standarde europene de interoperabilitate, promovate prin FIWARE şi SynchroniCity. • Documentaţia şi API-urile sunt publice şi accesibile oricărui furnizor, fără constrângeri de licenţiere. • Orice ofertant poate propune soluţii echivalente, cu condiţia să asigure aceleaşi mecanisme de interoperabilitate. • Conform art. 156 din Legea nr. 98/2016, autoritatea contractantă aplică principiul echivalenţei, iar menţiunea expresă „sau Pagina 23 din 95

echivalent" este implicit aplicabilă în cazul specificării unor standarde tehnice deschise. 4. Clarificări punctuale faţă de criticile din contestaţie: Obiecţie: Integrarea cu FIWARE și SynchroniCity restrânge concurenţa Autoritatea precizează că cele două platforme sunt open-source, dezvoltate cu fonduri europene şi fără caracter restrictiv. Cerinţa nu limitează accesul operatorilor economici, ci asigură interoperabilitate şi continuitate cu infrastructura digitală deja implementată. Obiecţie: Nu reprezintă standarde obligatorii Achizitoarea precizează că deşi nu sunt standarde reglementate legal, FIWARE şi SynchroniCity sunt recunoscute la nivel european pentru interoperabilitate, fiind incluse în iniţiative precum OASC şi Living-in.EU. Aplicarea lor este o alegere strategică justificată tehnic şi operaţional. Obiecţie: Se creează dependenţă de anumite tehnologii sau furnizori Autoritatea menționează că FIWARE şi SynchroniCity sunt utilizate şi dezvoltate de o comunitate internaţională diversificată, fără a depinde de un singur furnizor. Această deschidere reduce riscurile de exclusivitate şi asigură durabilitatea soluţiei în timp. Obiecţie: Lipsa formulării „sau echivalent" limitează soluţiile similare Achizitoarea precizează că cerinţa vizează mecanismele funcţionale de interoperabilitate, nu o implementare rigidă. În mod implicit, orice ofertant poate demonstra compatibilitatea prin soluţii echivalente, autoritatea contractantă urmând să aplice principiul echivalenţei consacrat de art. 156 alin. (2) din Legea 98/2016 privind achizitiile publice. Acest principiu a fost mentionat atât în Anexa 2 la caietului de sarcini (pag.90), intitulată Formular de Propunere tehnică, cât și la nivelul fișei de date, sectiunea IV.4.1 Modul de prezentare al propunerii tehnice. Obiecţie: Necesitatea cerinţei nu a fost justificată Autoritatea menționează că justificarea este oferită de strategia digitală a Municipiului Timişoara, care include deja implementări bazate pe FIWARE (ex: proiectul de video analytics) şi vizează construirea unui ecosistem urban coerent, interoperabil şi eficient pe termen lung. În concluzie, consideră că cerinţa privind integrarea cu platformele FIWARE şi SynchroniCity: • este justificată obiectiv şi proporţională cu nevoile sale; • nu restrânge concurenţa, fiind aplicabilă oricărui operator economic; • urmăreşte

protejarea

investiţiilor

publice

prin interoperabilitate, deschidere şi evitarea dependenţei tehnologice; Pagina 24 din 95

• este conformă cu legislaţia naţională şi europeană privind standardele tehnice şi echivalenţa. Cu privire la punctul V din contestaţie, Prin documentaţia de atribuire se solicită un număr semnificativ de integrări cu aplicaţii software și echipamente externe existente, precum și furnizarea unor funcţionalităţi viitoare și integrări cu sisteme „viitoare", fără furnizarea documentaţiei tehnice de integrare sau a oricăror alte detalii tehnice (punctele 60 - 72 din contestaţie): Contestatoarea susține că documentaţia de atribuire impune cerinţe excesive şi neclare, întrucât solicită integrarea cu aplicaţii şi echipamente deja existente (.., Omnia/Swarco, ERP ASSIS, totemuri, ecrane din vehicule), precum şi cu posibile sisteme viitoare (ride-sharing, trenuri regionale etc.), fără a furniza documentaţia tehnică necesară. Aceasta invocă riscul restrângerii concurenţei şi al avantajării furnizorilor actuali, în temeiul art. 50 şi art. 155 alin. (6) din Legea nr. 98/2016 privind proporţionalitatea şi tratamentul egal. Autoritatea contractantă respinge aceste susţineri, arătând următoarele: 1. Integrarea cu .. Achiziţia anterioară pentru .. a avut două componente distincte: • (a) Aplicaţia software .., care se doreşte înlocuită integral prin actualul proiect. Documentaţia ei nu este necesară, întrucât funcţionalitatea de planner/router este deja aproape un standard internaţional oferit prin API-uri publice de aplicaţii precum Google Maps şi Waze. Mai mult, autoritatea contractanta are parteneriat activ cu aceste platforme, ceea ce permite integrarea directă în ecosistemul şi comunitatea lor globală de soluţii. • (b) Ecranele şi totemurile montate în staţii şi vehicule sunt echipamente standard, cu sistem de operare Android. Integrarea lor se face conform API-urilor publice disponibile în ecosistemul Android/Google. Fişele tehnice ataşate (Dahua DHI-LDV65-EAO400K pentru totemuri, panouri LCD Rockchip RK3568 pentru vehicule) confirmă că aceste echipamente sunt deschise, rulează Android/Linux şi acceptă API-uri şi aplicaţii terţe. Remediere propusă prin clarificare din oficiu pe SEAP la documentatia achizitiei: Pentru a înlătura orice incertitudine legată de disponibilitatea informaţiilor tehnice referitoare la echipamentele de afişaj (respectiv totemurile din staţii şi ecranele din mijloacele de transport public), autoritatea contractantă va publica, în SEAP, o clarificare din oficiu care va include fişele tehnice corespunzătoare acestor echipamente. Această măsură are ca scop garantarea transparenţei, asigurarea unui acces echitabil la informaţii pentru toţi operatorii economici interesaţi şi respectarea principiilor concurenţei loiale prevăzute de Legea nr. 98/2016. Pagina 25 din 95

2. Integrarea cu sistemul Omnia/Swarco Autoritatea contractantă precizează că nu deţine în prezent API- urile sistemului Omnia folosit actualmente datorită faptului că acest lucru nu se regăseşte ca sarcină contractuală. Totodată, ofertantul câştigător va fi pus în contact cu dezvoltatorul sistemului de trafic management (Swarco) pentru un schimb cât mai facil de informaţii şi date. Pentru a evita ambiguităţi şi sarcini disproporţionate, autoritatea contractantă va limita integrarea la maximum 20 de funcţionalităţi (endpoint-uri), stabilite de comun acord cu operatorul selectat. 3. Integrarea cu ERP (ASSIS) Autoritatea menționează că se solicită doar posibilitatea tehnică de integrare prin standarde larg utilizate (HTTPS, JSON/XML, OAuth 2.0, OpenAPI/Swagger, versionare, audit, sandbox). Ca şi în cazul Omnia, integrarea va fi limitată la maximum 20 de endpoint-uri, stabilite de comun acord. 4. Integrarea cu sisteme viitoare Achizitoarea precizează că această cerinţă nu implică integrarea efectivă cu sisteme care nu există în prezent. Se solicită doar ca arhitectura tehnică a soluţiei să fie scalabilă, deschisă şi interoperabilă, în vederea posibilelor extinderi ulterioare (ex. FIWARE, SynchroniCity). Această abordare este conformă cu bunele practici europene privind evitarea dependenţei de furnizori unici („vendor lock-in") şi reducerea costurilor viitoare pentru autoritate. În concluzie, cerinţele PMT sunt proporţionale şi justificate de obiectivul proiectului: construirea unei platforme integrate şi interoperabile. Nu se creează avantaje pentru furnizorii existenţi, întrucât: • aplicaţia .. este înlocuită, nu integrată; • ecranele şi totemurile sunt Android standard, documentaţia fiind publică (cu documentatiile fiselor tehnice atasat la răspuns); • Omnia şi ASSIS vor expune un set limitat de API-uri standardizate; • integrarea cu sisteme viitoare vizează doar capabilitatea arhitecturii. Referitor la punctul VI din contestaţie: Documentaţia de atribuire cuprinde cerinţe tehnice care nu au legătura cu obiectul contractului de achiziţie publica, care exced obiectului acestuia sau care sunt disproporţionate prin raportare la obiectivele acestuia VI.A - Specificaţii privind cardurile contactless (pentru dimensionarea validatoarelor) Autoritatea susține că menţionarea parametrilor cardurilor (compatibilitate ISO/IEC 14443 A/B, timpi de răspuns, suport anti- coliziune, capabilităţi de criptare, gestionarea cheilor) este strict necesară pentru dimensionarea corectă a validatoarelor (HW + firmware), definirea interoperabilităţii cu titlurile de călătorie şi Pagina 26 din 95

prevenirea riscului de achiziţie a unor validatoare care nu pot citi suporturile planificate în proiect (card, token, NFC). Cerinţa este legată de obiectul contractului (validare e-ticketing), proporţională şi formulată cu neutralitate tehnologică, fiind totodată însoţită de sintagma „sau echivalent" conform specificaţiilor din caietul de sarcini. Specificaţiile tehnice au fost concepute astfel încât să nu restrângă concurenţa şi in acelaşi timp să urmărească performanţa necesară. În concluzie, menţiunile privind cardurile nu „condiţionează" piaţa, ci stabilesc reperul de performanţă pentru validatoare şi interfaţa lor cu suporturile de călătorie, respectând proporţionalitatea şi transparenţa. VI.B - Găzduire în cloud/DataCenter, RACI şi abordarea integrată (validată în proiectele anterioare) Răspuns: Autoritatea contractantă precizează că a aplicat aceeaşi abordare integrată în mai multe proiecte IT majore anterioare (de ex. portalul cont.primariatm.ro, cloud storage, GIS găzduit în cloud). În toate aceste proceduri s-au precizat cerinţe tehnice de găzduire/operare şi s-a introdus explicit un RACI (Responsabil, Aprobare, Consultat, Informat) pentru claritatea responsabilităţilor între ofertant, furnizorul de infrastructură şi autoritatea contractantă. Rezultatul: proiectele au evitat probleme de integrare sau incompatibilităţi între componente livrate de entităţi diferite şi au asigurat o continuitate operaţională ridicată. Această practică validată este reprodusă şi aici pentru a proteja serviciul public şi investiţia. Juridic, documentaţia de atribuire trebuie să asigure informare completă, corectă şi explicită asupra cerinţelor. Cerinţele de cloud/datacenter şi guvernanţă (RACI) sunt necesare şi proporţionale cu complexitatea proiectului şi cu obligaţiile de securitate şi rezilienţă (NIS2, transpusă prin OUG 155/2024) - managementul riscurilor cibernetice, SLA/disponibilitate, continuitate (RTO/RPO), logare/audit, raportarea incidentelor, securitatea lanţului de aprovizionare. Cerinţele nu urmăresc restrângerea concurenţei. După cum s-a precizat în caietul de Sarcini, la punctul 8.3.2 Cerinţe la nivel de DataCenter - Pentru asigurarea securităţii fizice a locaţiei, soluţia oferită în Cloud (DataCenter) trebuie să respecte cerinţele minime din ORDINUL nr. 489 din 15 iunie 2009 privind normele metodologice de autorizare a centrelor de date, cu toate modificările ulterioare din 2011, emis de Ministerul Comunicaţiilor și Societăţii Informaţionale. Opţiuni acceptate (fără a limita concurenţa pe piaţă): • Cloud public în UE/SEE (certificări ISO 27001/27017/27018, SOC 2 sau echivalent), KMS dedicat, criptare at-rest/in-transit; sau • DataCenter local cu EN 50600/Tier III echivalent, redundanţe N+1 şi SLA garantat. În ambele variante, ofertantul livrează un RACI defalcat pe faze (inception, proiectare, migrare, operare, suport. Ambele opţiuni menţionate mai sus sunt disponibile în România. Pagina 27 din 95

În ceea ce privește punctul VII din contestaţie: Mai multe menţiuni din documentaţia de atribuire nu asigură o informare completă, corectă și precisă cu privire la cerinţele achiziţiei și modul de desfăşurare a procedurii de atribuire Autoritatea precizează că documentaţia este redactată pentru a permite operatorilor o informare completă, corectă şi explicită, iar specificaţiile sunt legate de obiect, în linie cu Considerentul (74) al Directivei

2014/24/UE

privind

deschiderea

concurenţei

şi interoperabilitatea. În plus, se urmăreşte compatibilitatea cu standardele europene de date pentru transport (Transmodel/EN 12896, NeTEx, SIRI), cu arhitectura ITxPT (interoperabilitate „plug-and-play") şi cu OJP (CEN/TS 17118) pentru planificare distribuită - toate sprijinite de noul cadru Interoperable Europe Act. Cu privire la punctul VII.1 — Metodologia de livrare a sistemului (pondere 25 pct.), autoritatea menționează că scopul evaluării este să distingă metodele care demonstrează fezabilitate, interoperabilitate, securitate şi un calendar realist, în condiţiile unui proiect IT integrat, operat 24/7. Baremele stabilesc repere clare privind rezultatele aşteptate, fără a substitui responsabilitatea ofertantului în elaborarea propriei metodologii. Autoritatea nu defineşte soluţia tehnică în locul operatorului economic, ci indică obiectivele şi criteriile de evaluare care trebuie atinse, lăsând libertatea de a propune abordarea optimă. Subfactor

1

(10

pct.)

—

Arhitectura

sistemului (FIWARE/SynchroniCity sau echivalent) & lista de API- uri Se evaluează: coerenţa arhitecturii, decompoziţia pe module, respectarea principiilor de interoperabilitate (context broker, management de evenimente), lista de API-uri expuse/consumate (inclusiv pentru integrări cu ERP/facturare, portal, panouri, validatoare, aplicaţii mobile), strategia de versiuni şi observabilitate. Au fost precizate Capitolul 4 respectiv Capitolul 7 Bareme: • 10 pct. (Complet): arhitectură end-to-end, diagrame şi descrieri detaliate; aliniere explicită la FIWARE/SynchroniCity sau echivalent (ex.: NGSI-LD/Context Broker) + inventar API per componentă (metode, formate, securizare, rate-limit), mapare la Transmodel/NeTEx/SIRI acolo unde e cazul, şi la ITxPT pentru on-board. • 4 pct. (Partial) arhitectură completă sau generalistă, dar cu unele API-uri sumarizate; principiile de interoperabilitate sunt descrise, însă fără mapare exhaustivă la standarde, lipsesc clarificări privind API- urile critice sau conformarea la standarde. • 0 pct.: lipsesc elemente esenţiale; nu se pot deduce integrările. Justificare: susţine interoperabilitatea şi evită vendor lock-in, exact cum recomandă cadrele FIWARE/OASC MIMs şi Interoperable Europe. Având în vedere arhitectura deschisă, modulară, bazată pe standardele FIWARE şi SynchroniCity, care asigură interoperabilitate şi scalabilitate, Pagina 28 din 95

fiecare componentă e necesar să fie documentată cu API-uri RESTful, specificând direcţia şi tipul de date schimbate. Standardele FIWARE fiind utilizate pentru context data management (ex: Orion Context Broker), iar SynchroniCity oferind cadrul pentru integrarea urbană şi interoperabilitatea cu alte oraşe inteligente, adoptarea unei arhitecturi deschise şi standardizate garantează un sistem robust, interoperabil şi uşor de extins în viitor. Subfactor 2 (7 pct.) — Strategia .. vs. dezvoltare specifică Ce se evaluează: identificarea clară a componentelor .. (Commercial-Off-The-Shelf) şi a celor custom, argumentarea alegerii (TCO, mentenanţă, actualizări), planul de integrare şi migrare (inclusiv evitarea dublării funcţiilor). Bareme: • 7 pct.: listă ../custom la nivel de modul, criterii de selecţie (performanţă, licenţiere, securitate), plan de migrare şi strategie de actualizare; demonstrarea că .. nu compromite standardele (Transmodel/NeTEx/SIRI, ITxPT). • 3 pct.: listă parţială; criterii sumare; lipsesc unele detalii privind actualizările. • 0 pct.: abordare vagă; risc de sisteme paralele sau lock-in. Justificare: optimizează costul total şi acceleră livrarea fără a sacrifica conformitatea la standarde şi integrarea în ecosistem. Identificarea clară a componentelor .. şi a celor dezvoltate la comandă permite o evaluare corectă a gradului de personalizare şi a costurilor implicite. Componentele .. trebuie să fie configurabile şi să ofere mecanisme transparente de expunere a datelor (API-uri, sincronizări), pentru a asigura integrarea cu alte sisteme. Drepturile de utilizare şi proprietate sunt esenţiale pentru sustenabilitatea proiectului. Un echilibru între reutilizarea componentelor .. şi dezvoltarea personalizată optimizează costurile şi asigură controlul Beneficiarului asupra soluţiei livrate. Subfactor 3 (5 pct.) — Arhitectura de securitate (Zero-Trust) & conformare NIS2 Ce se evaluează: controlul accesului (IAM/MFA), segmentarea (micro-segmentare), criptarea, monitorizarea şi răspunsul la incidente, controlul furnizorilor (lanţ de aprovizionare), logging/audit, BCP/DR şi RTO/RPO; coerenţă cu RACI. Bareme: • 5 pct.: arhitectură Zero-Trust, politici IAM/MFA, criptare end- to-end, plan de răspuns la incidente aliniat OUG 155/2024 (NIS2), logare/audit, BCP/DR cu RTO/RPO măsurabile, responsabilităţi RACI pe fiecare control. • 3 pct.: elemente principale prezente, dar fără metrifici sau fără mapare completă la RACI/NIS2. • 0 pct.: măsuri generale; lipsesc proceduri operaţionale. Pagina 29 din 95

Justificare: minimizarea expunerii şi asigurarea rezilienţei pentru un sistem cu impact public. Implementarea unei arhitecturi de securitate bazate pe principiul Zero Trust minimizează riscurile de acces neautorizat şi atacuri cibernetice. Conformitatea cu directiva NIS2 este esenţială pentru protejarea infrastructurilor critice. Mecanismele de autentificare, criptare, audit şi backup trebuie să fie integrate nativ în sistem. O arhitectură de securitate solidă şi conformă cu NIS2 oferă încredere, protecţie şi rezilienţă cibernetică pe termen lung. Subfactor 4 (3 pct.) - Planul de implementare şi calendarul Ce se evaluează: WBS, dependenţe, criterii de acceptanţă, testare/UAT, cut-over şi hiper-care. Bareme: • 3 pct.: plan granular (milestone-uri, livrabile, resurse), criterii de acceptanţă pe livrabile, strategie UAT şi plan de tranziţie în producţie (cut-over) + hiper-care. • 2 pct.: plan general; lipsesc criterii de acceptanţă/hiper-care. • 0 pct.: calendar lipsă sau necorelat cu resursele. Justificare: reducerea riscurilor de derapaj şi neconformitate la recepţie (art. 83 - informare completă). În ceea ce privește punctul VII.2 - Experienţa similară Autoritatea susține că cerinţele sale în acest sens sunt în conformitate cu prevederile Instrucţiunii ANAP nr. 2/2017 emisă în aplicarea prevederilor art. 178 şi art. 179 lit. a) şi b) din Legea nr. 98/2016 privind achiziţiile publice, cu completările ulterioare (...). Cu privire la observaţiile de la punctul 95 - Caracteristicile minime și cumulul între contracte Cerinţa formulată în documentaţia de atribuire este clară în sensul că permite îndeplinirea cerinţei printr-un singur contract sau prin cumulul a cel mult trei contracte, astfel cum este expres menţionat: „...la nivelul a minim un contract - maxim trei contracte... " Această formulare stabileşte în mod explicit că experienţa poate fi dovedită cumulativ, în limita a maximum trei contracte, fapt care este perfect conform cu practica în domeniul achizitiilor publice. Autoritatea contractantă are dreptul să stabilească, în mod rezonabil şi justificat, condiţii care să reflecte complexitatea contractului ce urmează a fi atribuit, permiţând cumulul experienţei între mai multe contracte, atâta timp cât acest lucru este prevăzut expres. Justificarea cerinţei: Pentru a asigura desfăşurarea în condiţii optime a proiectului şi atingerea obiectivelor stabilite, este esenţial ca ofertanţii să deţină o experienţă relevantă şi o capacitate tehnică adecvată în domeniul vizat. În acest sens, s-a solicitat prezentarea unor dovezi clare privind implicarea anterioară în proiecte similare, care să reflecte nivelul de competenţă, complexitatea soluţiilor livrate şi capacitatea de a gestiona cerinţe tehnice şi funcţionale avansate. Această cerinţă permite autorităţii contractante să evalueze în mod Pagina 30 din 95

obiectiv experienţa fiecărui ofertant şi să se asigure că viitorul contractant va putea răspunde eficient provocărilor specifice proiectului. Astfel, interpretarea corectă este că toate caracteristicile minime solicitate (volum, trafic, integrare metode de plată) pot fi dovedite prin cumularea a maximum trei contracte, fiecare contribuind cu părţi relevante din cerinţele impuse. 2. Cu privire la observaţiile de la punctul 96 - Componentele tehnice: emitere, validare, backend În ceea ce priveşte cerinţa referitoare la cele trei componente tehnice, formularea: „soluţia implementată a acoperit cel puţin următoarele componente..." , nu impune în mod restrictiv ca toate aceste componente să fie îndeplinite în cadrul unui singur contract, ci, în contextul enunţului precedent („... la nivelul a minim un contract - maxim trei contracte... "), este logic şi rezonabil să se accepte că aceste componente pot fi acoperite cumulativ între cele cel mult trei contracte admise. Interpretare funcţională: • Dacă autoritatea contractantă ar fi dorit impunerea unui caracter individual (toate componentele în fiecare contract), ar fi utilizat formulări precum: - „fiecare contract trebuie să includă " sau - „se acceptă doar contracte care conţin integral toate componentele menţionate". Or, o asemenea formulare restrictivă nu există în text. Prin urmare, interpretarea rezonabilă şi legală este că: • cele trei componente pot fi dovedite în ansamblu prin maximum trei contracte, • şi nu fiecare contract trebuie să conţină toate cele trei componente. Concluzie: Formularea din fişa de date este: • clară, în sensul că permite cumulul între cel mult trei contracte; • nerestrictivă, permiţând participarea unor operatori economici care pot dovedi experienţă relevantă în mod cumulativ; • conformă cu principiile nediscriminării şi proporţionalităţii. Cu privire la punctul VII.3 — Integrarea cu ERP / sistemul de facturare si RO e-Factura Referitor la observaţiile de la punctele 98 - 99: Integrarea este bidirecţională, limitată la schimbul de date necesar (titluri/abonamente, reduceri, vânzări/încasări, documente contabile), pentru a evita sisteme paralele. Vânzarea titlurilor şi managementul tarifar se realizează exclusiv în noul sistem de e-ticketing, iar ERP generează/gestionează documentele fiscale, inclusiv prin mecanismele native de RO e-Factura. Cadrul legal a fost întărit prin Legea 126/2024, care recunoaşte factura electronică emisă/transmisă/primita prin Pagina 31 din 95

sistemul naţional şi consolidează regimul sancţionator - de aici necesitatea alinierii integrărilor. Răspunsul autorităţii contractante la punctul VII.4 - Gateway SMS & dimensionarea volumului în garanţie Cu privire la observaţiile de la punctele 100 - 103: Volumul de SMS depinde de scenariile stabilite (MFA/OTP, alerte), de adopţia utilizatorilor şi de politicile de securitate. De aceea, documentaţia prevede „Inception Report" şi „Analiză-Proiectare" pentru a dimensiona fundamentat (ipoteze de trafic, profiluri, mix tehnic SMS/Push/TOTP), a optimiza costurile şi a valida metode alternative de autentificare. Solicitarea acestor livrabile este proporţională cu complexitatea proiectului şi asigură comparabilitatea ofertelor. Mai multe detalii s-au prezentat la punctul III.1. Cu privire la Subsecţiunea 4.2.7.1 - „Inception Report" si „Analiză - Proiectare" Referitor la punctul VII.5 — Panouri de informare a călătorilor Cu privire la observaţiile de la punctele 104 - 107: Se urmăreşte standardizarea: un singur tip de afişaj capabil să redea dinamic 2-5 rânduri prin ajustarea mărimii fontului, pentru a asigura lizibilitatea şi a simplifica mentenanţa. Integrarea în timp real se bazează pe formate deschise (ex.: SIRI/GTFS-Realtime), cu cerinţe minime de interfeţe şi protecţie IP. Nu se solicită montaj, autorizaţie de construire sau lucrări conexe - acestea vor fi realizate de autoritatea contractantă. Delimitarea menţine proporţionalitatea şi claritatea obiectului (produse/servicii, fără lucrări pe partea de panouri). Aceste precizări se aplică strict în contextul prezentului punct din contestaţie şi nu se extind asupra altor categorii de echipamente sau lucrări prevăzute în documentaţie. Prin adresa înregistrată la Consiliu sub nr. 61426/03.09.2025, contestatoarea a formulat cerere de studiere a dosarului achiziției publice. Prin adresa înregistrată la Consiliu sub nr. 64175/15.09.2025, contestatoarea a formulat concluzii scrise. Prin adresa înregistrată la Consiliu sub nr. 64175/15.09.2025, contestatoarea a formulat concluzii scrise. Prin adresa înregistrată la Consiliu sub nr. 64276/16.09.2025, contestatoarea a depus traducerile autorizate ale Anexelor 1-5 atașate la concluziile scrise. Prin adresa TMI2025-040207/19.09.2025, înregistrată la Consiliu sub nr. 65705/22.09.2025, autoritatea a formulat răspuns la concluziile scrise depuse de contestatoare. Din examinarea materialului probator administrat, aflat la dosarul cauzei, Consiliul reține următoarele: .. a inițiat procedura de licitație deschisă, organizată în vederea atribuirii contractului de furnizare având ca obiect ., cod CPV 34970000-7 Echipament de monitorizare a traficului (Rev.2), prin publicarea în SEAP Pagina 32 din 95

a anunțului de participare nr. ., data limită de depunere a ofertelor fiind stabilită pentru 23.09.2025, ora 1500. Valoarea estimată a contractului de furnizare este 34.873.949,58 lei, fără TVA. Nemulțumită fiind de unele prevederi ale documentaţiei de atribuire, .. SA a depus contestația în analiză, solicitând cele precizate în partea introductivă a deciziei. Contestatoarea a constituit cauțiunea în sumă de 220.000,00 lei, conform art. 611 alin. (1) lit. b) din Legea nr. 101/2016, fiind depusă la dosar recipisa de consemnare nr. . eliberată de CEC Bank – Sucursala Victoria, la data de 25.08.2025. Prin Încheierea nr. ., Consiliul a admis cererea de suspendare a procedurii, formulată de .. SA. Analizând criticile formulate de autoarea contestației, Consiliul constată că acestea vizează aspecte legate de faptul că documentaţia de atribuire cuprinde o serie de neconformităţi ce trebuie remediate, respectiv: (i) Obiectul achiziţiei nu este în corespondenţă cu Codul CPV principal care îl descrie cel mai exact (a se vedea Secţiunea II din prezenta Contestaţie); (ii) Cerinţele prevăzute la Secţiunea 4.2.7. Alte cerinţe din Caietul de sarcini sunt disproporţionate şi restrictive (a se vedea Secţiunea III din prezenta Contestaţie); (iii) Cerinţa stabilită prin Caietul de sarcini ca sistemul nou de e- ticketing să ofere integrare cu platformele FIWARE şi SynchroniCity determină restrângerea artificială a concurenţei (a se vedea Secţiunea IV din prezenta Contestaţie); (iv) Prin documentaţia de atribuire se solicită un număr semnificativ de integrări cu aplicaţii software şi echipamente externe existente, precum şi furnizarea unor funcţionalităţi viitoare si integrări cu sisteme "viitoare", fară furnizarea documentaţiei tehnice de integrare sau a oricăror alte detalii tehnice (a se vedea Secţiunea V din prezenta Contestaţie); (v) Documentaţia de atribuire cuprinde cerinţe tehnice care nu au legătură cu obiectul contractului de achiziţie publică, care exced obiectul acestuia sau care sunt disproporţionate prin raportare la obiectivele acestuia (a se vedea Secţiunea VI din prezenta Contestaţie); (vi) Mai multe menţiuni din documentaţia de atribuire nu asigură o informare completă, corectă şi precisă cu privire la cerinţele achiziţiei şi modul de desfăşurare a procedurii de atribuire. Ăn special documentaţia de atribuire nu descrie în mod clar modalitatea de îndeplinire a criteriilor de selecţie privind experienţa similară şi modalitatea în care va fi acordat punctajul aferent fiecărui Subfactor de evaluare în contextul criteriului de atribuire cel mai bun raport calitate preţ. (a se vedea Secţiunea VII din prezenta Contestaţie). Se vor reține și precizările aduse de autoritatea contractantă în replică la cele reclamate, respectiv faptul că, în afara punctului VI, care priveşte specificaţii tehnice referitoare la carduri (aspect colateral), toate celelalte critici formulate de contestatoare vizează exclusiv cerinţe care au ca scop asigurarea interoperabilităţii, prevenirea dependenţei Pagina 33 din 95

tehnologice („vendor lock-in"), promovarea standardelor deschise şi evitarea creării de sisteme paralele. Achizitoarea susține că aceste principii nu reprezintă simple opţiuni strategice ale autorităţii contractante, ci constituie obligaţii legale şi obiective strategice consacrate: • la nivel european, prin Regulamentul (UE) 2024/903 - Interoperable Europe Act şi Programul „Europa Digitală", care impun statelor membre să adopte soluţii interoperabile şi reutilizabile; • la nivel naţional, prin Legea nr. 242/2022 privind schimbul de date între sisteme informatice şi crearea Platformei Naţionale de Interoperabilitate (PNI), care consacră principiul „o singură dată" şi obligă autorităţile să evite barierele tehnologice şi duplicarea sistemelor; • prin H.G. nr. 908/2017 pentru aprobarea Cadrului Naţional de Interoperabilitate, care stabileşte cerinţe obligatorii pentru integrarea şi interoperabilitatea sistemelor informatice publice. Astfel, concluzia la care ajunge achizitoarea este aceea că petitele formulate nu urmăresc corectarea unor presupuse neclarităţi sau disproporţionalităţi, ci tind să împiedice integrarea cu sistemele existente şi să menţină soluţii proprietare, contrar cadrului normativ european şi naţional. Achizitoarea a adăugat și faptul că cerinţele contestate sunt, dimpotrivă, menite să asigure conformitatea legală, protejarea investiţiilor publice şi crearea unui ecosistem digital coerent, deschis şi sustenabil. Înainte de a proceda la analiza pe fond a aspectelor sesizate de .. SA, Consiliul găseşte util expunerea câtorva elemente din cadrul documentaţiei de atribuire, menite să înlesnească înţelegerea ei, cât şi să îi circumstanţieze soluţionarea. Obiectul suspus procedurii de atribuire îl constituie, potrivit pct. II.1.4-Descrierea succinta a contractului sau a achizitiei/achizitiilor din fișa de date: II.1.4 Descrierea succinta a contractului sau a achizitiei/achizitiilor Contractul ce urmează a fi atribuit presupune furnizarea unui sistem nou de e-ticketing, care sa respecte cerintele Caietului de sarcini, si anume: - Sa aibe o soluție cloud disponibila cel puțin intr-un cloud public; - Sa aibe o infrastructura de date si procesare care trebuie sa corespunda unui sistem complet, securizat, disponibil 24/7 care cu arhitectura datelor si serviciilor într-un cloud public si, opțional, într-un centru de date local, precum si un plan de recuperare in caz de dezastre. Acest plan de dezastre sa fie scriptat, operabil la comanda, sa fie testabil la livrare si într-un context real cel puțin odată la 6 luni; - Sa folosească ultimele tehnologii in domeniul de taxare, monitorizare a flotei, distribuire de conținut audio-video pe ecrane si soluții antifraudă; - Sa folosească tehnologii care sa expună datele prin API-urile dintre componente. Orice .. va avea datele expuse printr-un API deschis, iar datele sunt proprietatea autorității contractante; - Sa ofere o platforma web publica pentru administrarea conturilor ABT si planning; - Sa furnizeze serviciile oferite pentru cetățeni ca parte integranta in platforma de portal unic cont.primariatm.ro care este proprietatea autorității contractante; - Sa ofere integrare cu portalul Primăriei Timișoara, (cont.primariatm.ro) cu autentificare de tip single sign-on (SSO) unde cont.primariatm.ro este sursa funcționalității de autentificare; Pagina 34 din 95

- Sa ofere o opțiune de aplicație mobila pentru cetățeni (utilizatorul final) pentru administrarea conturilor ABT, planificarea călătoriilor si validarea călătoriei; - Sa ofere opțiuni facile (implementata cu/pe telefonul mobil de tip smart, cu camera si sistem de plata cu NFC) pentru validarea călătoriilor de către controlori; - Sa permită interconectări si extragere de date securizat cu alte platforme ale autorității contractante; -

Sa

ofere

integrare

cu

platforma

european

SynchroniCity (https://www.synchronicityiot.eu/knowledge/technical-framework/) - Sa ofere integrare cu platforma FIWARE (https://www.fiware.org/about-us/) FIWARE este o platformă open-source care facilitează dezvoltarea de aplicații inteligente pentru diverse domenii, inclusiv orașele inteligente. Aceasta oferă un set de componente reutilizabile, cunoscute sub numele de Generic Enablers (GEs), care permit colectarea, gestionarea și analiza datelor în timp real. Autoritatea contractanta va raspunde in mod clar si complet tuturor solicitarilor de clarificare /informatii suplimentare, in a 12-a zi înainte de termenul limita stabilit pentru depunerea ofertelor, in conditiile in care solicitarile se vor adresa cu cel putin 22 zile înainte de termenul limita stabilit pentru depunerea ofertelor. Clarificarile depuse dupa acest termen nu vor mai fi luate in considerare. Sunt relevant de redat și mențiunile de la pct. II.2.4 Descrierea achizitiei publice din fișa de date: Sistemul de e-ticketing ce face obiectul prezentei achizitii este un element cheie in Solutia “Cross Platform” mobiliTM pe care Beneficiarul dorește sa o implementeze. Totuși, pentru ca integrarea platformei sa funcționeze, este necesar ca Sistemul de eticketing sa aibă la baza o serie de informații si reguli standardizate de schimb de informații in format securizat. Pentru realizarea acestui deziderat, se vor folosi tehnologii sustinute de Uniunea Europeana prin strategia “Digital Agenda 2020” si anume Fiware FIWARE – a European success story | Shaping Europe’s digital future Platforma mobiliTM, oferă o gamă variată de funcționalități pentru cetățeni, companii și orașe. În diagrama de mai jos este prezentată arhitectura modulară a platformei mobiliTM, care va livra in cadrul acestui caiet de sarcini prin sistemul de e-Ticketing, FIWARE este o platformă open source concepută pentru a facilita dezvoltarea aplicațiilor inteligente în diverse sectoare, inclusiv mobilitatea urbană. Integrarea funcționalităților sistemului de e-Ticketing in soluțiile cloud scalabile FIWARE va fi utilizat ca backbone pentru arhitectura sistemului livrat pentru a integra diverse componente ale unei platforme de mobilitate prin următoarele modalități. Următoarele funcționalități vor fi furnizate in acest proiect integrate toate in FIWARE si cu API-uri la nivel de fiecare componenta; Componenta de taxare/procesare de plăți (e-TAX): Componenta de e-Monitorizare si Informare calatori (e-MIC) - - Planificarea traseelor: - Gestionarea conținutului audio-video: - Video analytics: - Sistemul de antifraudare: - Sistemul de control al ecranelor si notificare/publicitate: - Analiza si controlul traficului: Interoperabilitate: - FIWARE facilitează interoperabilitatea între diverse sisteme și platforme, permițând integrarea ușoară a noilor servicii și tehnologii în platforma de mobilitate. Raportare: - Sa se creeze o arhitectura de dashboard integrata bazata pe sisteme de business intelligence (BI) de tip Tableau sau Power BI care sa aibe incluse in oferta licentierea pe perioada acestui proiect (inclusive perioada de garantie) pentru cel putin 50 de uilizatori precum si toata infrastructura de client/server necesara; Scalabilitate: - Sa ofere posibilitatea unei scalabilitati dinamice a solutiei software prin utilizarea orchestratoare de tip Kubernetes sau echivalent și containerizare de tip Docker sau echivalent; - Sa ofere posibilitatea de instalare atat în Cloud cât și pe computere fizice/virtuale, daca se doreste; Pagina 35 din 95

Sistemul de e-Ticketing trebuie sa se integreze Cross-Platform cu Portalul Unic al Primaria Timisoara. Portalul Unic al Primăriei Timișoara este o platformă digitală complexă lansată pentru a facilita interacțiunea cetățenilor cu administrația locală Arhitectura de Business Intelligence, raportare si analiza Propunerea ofertata va trebui sa asigure cel puțin aceste funcționalități. Acest proiect va furniza o platformă puternică de vizualizare a datelor și business intelligence (BI), utilizată pentru a analiza, interpreta și prezenta datele într-un mod interactiv și intuitiv. Aceasta platforma permite utilizatorilor să creeze dashboarduri statice si dinamice care oferă perspective detaliate asupra datelor din diverse surse. Aceasta solutie va fi integrata si livrata in solutia de cloud. Componentele principale ale BI: • Funcționalitate pentru Desktop – Solutia va oferi posibilitatea de a crea vizualizări, analize și dashboard-uri. • Funcționalitate pentru Cloud (server) – Serverul unde se va face partajarea și colaborarea pe vizualizări și dashboard-uri. • Funcționalitate de tip Prep procesare/pregatire – Salutia va oferi si un instrument pentru pregătirea și curățarea datelor înainte de analiză. • Funcționalitate pentru Public – Solutia va oferi si o versiune gratuită pentru publicarea și partajarea vizualizărilor în mod deschis catre oras. Solutia de BI se va conecta la o toate sursele de date generate prin API-urile funcționalităților livrate in acest proiect. Utilizatorii acestui sistem vor putea trage și plasa câmpuri pentru a construi diagrame, tabele și hărți interactive, cum ar fi: • Grafice cu bare și coloane. • Linii de tendință și analize predictive. • Hărți geografice și analize spațiale – integrarea se va face cel putin cu Google Maps si standardul Google Transit. • Tabele pivot și scorcard-uri KPI. Dashboard-urile din BI vor combina mai multe vizualizări pentru a oferi o perspectivă completă. Functionalitati esențiale oferite: • Filtre interactive – utilizatorii pot filtra datele în timp real. • Drill-down – explorare detaliată prin clic pe elemente specifice. • Live Data Refresh – actualizări automate ale datelor. • Storytelling – crearea de scenarii și povești bazate pe date. Acest model va fi proiectat sa poata acorda drepturi de editare si vizualizare pe echipe și pe companii/operatori. Vor exista cel putin trei tipuri principale de utilizatori: • Utilizator de tip Dashboard Creator • Utilizator de tip Dashboard Explorer • Utilizator de tip Dashboard Viewer Sistemul va include si toate licentele de tip cloud, server si enterprise necesare pentru implementarea solutie de BI pentru colectarea, stocarea si procesarea datelor venite din API si vor fi integrate in sistemul de backup si in planul de recuperare la dezastru. În cuprinsul caietului de sarcini autoritatea contractantă a detaliat contextul contractului ce urmează a fi atribuit, respectiv: Caietul de sarcini este elaborat în conformitate cu prevederile Legii 98/2016 şi are în vedere stabilirea caracteristicilor tehnice solicitate de Autoritatea Contractanta, care vor sta la baza contractului de furnizare necesare pentru implementarea platformei de mobilitate. Caietul de sarcini cuprinde şi descrie serviciile ce vor fi prestate, respectiv produsele ce vor fi furnizate (furnituri) in cadrul contractului de achiziţie publică. (...) 2.5.2 Sistemul actual de taxare Serviciul public de transport din oraşul Timişoara este dotat cu Sistem Automat de colectare a tarifelor (AFC) bazat pe carduri contactless şi este operaţional din 2009. Acest sistem cuprinde mai multe componente funcţionale, inclusiv formatarea cardului, personalizarea specifică a utilizatorului pe baza tipului de permis de călătorie în timpul emiterii/vânzărilor, validării şi controlului călătoriei în cadrul vehiculelor de transport. Pagina 36 din 95

Până acum sistemul AFC existent nu a fost niciodată modernizat, în afară de unele mici reparaţii şi întreţinere a unor componente. În domeniul mobilităţii urbane, Operatorul joacă un rol crucial în oferirea de opţiuni de călătorie convenabile şi accesibile pentru timişoreni şi vizitatori. Ca atare, unul dintre principalele aspecte care trebuie luate în considerare a fost producerea biletelor de călătorie. Vânzarea biletelor de călătorie se realizează în principal prin reţeaua proprie de distribuţie a Operatorului, utilizând un sistem tarifar automatizat, prin propriile puncte de vânzare (în număr de 17) dotate cu terminale POS pentru plăţi cu cardul. Biletele şi abonamentele de o zi, în format hârtie, pot fi achiziţionate şi de la companiile care vând bilete de călătorie pe bază de contracte încheiate cu firma, în schimbul unui comision. În anul 2022, sistemele moderne de plată pentru tarifele de călătorie au fost menţinute alături de canalele/modelele tradiţionale de distribuţie a biletelor de călătorie prin propriile puncte de vânzare şi afaceri. Aceste sisteme au inclus: sistemul de plată prin telefonul mobil prin aplicaţia 24Pay, care se bazează pe tehnologiile QR/NFC. Pasagerii au opţiunea de selecţie rapidă şi plată sigură. Sistemul POS pentru plăţi cu cardul în mijloacele de transport în comun, implementat în colaborare cu Banca Comercială Română, a fost cel mai de succes sistem. În plus, un alt sistem de plată modern a fost implementat prin SMS şi aplicaţia mobilePay Wallet. Verificarea plăţii sau validarea cursei este efectuată de controlorii Operatorului la bordul vehiculelor de transport, la validatoare. (...) Obiectul acestei achiziţii îl reprezintă achiziţia unui sistem nou de e-ticketing care: - Sa aibă o soluţie cloud disponibila cel puţin intr-un cloud public; - Sa aibă o infrastructura de date si procesare care trebuie sa corespunda unui sistem complet, securizat, disponibil 24/7 care cu arhitectura datelor si serviciilor într-un cloud public si, într-un centru de date local, precum si un plan de recuperare in caz de dezastre. Acest plan de dezastre sa fie criptat, operabil la comanda, sa fie testabil la livrare si într-un context real cel puţin odată la 6 luni; - Sa folosească ultimele tehnologii in domeniul de taxare, monitorizare a flotei, distribuire de conţinut audio-video pe ecrane si soluţii antifraudă; - Sa folosească tehnologii care sa expună datele prin API-urile dintre componente. Orice .. va avea datele expuse printr-un API deschis, iar datele sunt proprietatea autorităţii contractante; - Sa ofere o platforma web publica pentru administrarea conturilor ABT si planning; - Sa furnizeze serviciile oferite pentru cetăţeni ca parte integranta in platforma de portal unic cont.primariatm.ro care este proprietatea autorităţii contractante; - Sa ofere integrare cu portalul Primăriei Timişoara, (cont.primariatm.ro) cu autentificare de tip single-sign-on (SSO) unde cont.primariatm.ro este sursa funcţionalităţii de autentificare; - Sa ofere o opţiune de aplicaţie mobila pentru cetăţeni (utilizatorul final) pentru administrarea conturilor ABT, planificarea călătoriilor si validarea călătoriei; - Sa ofere opţiuni facile (implementata cu/pe telefonul mobil de tip smart, cu camera si sistem de plata cu NFC) pentru validarea călătoriilor de către controlori; - Sa permită interconectări si extragere de date securizat cu alte platforme ale autorităţii contractante; - Sa ofere integrare cu platforma europeana SynchroniCity (. - Sa ofere integrare cu platforma FIWARE (. FIWARE este o platformă open-source care facilitează dezvoltarea de aplicaţii inteligente pentru diverse domenii, inclusiv oraşele inteligente. Aceasta oferă un set de componente reutilizabile, cunoscute sub numele de Generic Enablers (GEs), care permit colectarea, gestionarea şi analiza datelor în timp real.. - Sa permita accesarea individuala din backoffice a tuturor echipamentelor din sistem pentru scopuri de diagnoza sau upgrade firmware - Sa respecte si sa prezinte in Formularul de Propunere Tehnica solicitarile Autoritatii Pentru Digitalizarea Romaniei: ✓ Mecanisme de autentificare utilizatori şi administratori conform Zero - Trust Security Model ✓Testare whitebox a componentelor dezvoltate Pagina 37 din 95

✓Implementare mecanisme de API Rate Limiting ✓Sa corespunda specificatilor WCAG. Luând în considerare ansamblul considerentelor expuse, Consiliul are în vedere complexitatea contractului de furnizare (care cuprinde și prestarea de servicii aferente), importanța acestuia, durata contractuală și rezultate așteptate de la derularea proiectului, asigurarea posibilității depunerii unor oferte conforme, precum și specificacitatea acestuia (caietul de sarcini, descrie un sistem informatic complex - o platformă digitală integrată de mobilitate urbană, care include o serie de componente şi funcţionalităţi) aspect care implica o atenție sporită din partea autorității contractante astfel încât să poată fi asigurată derularea proiectului. Așa cum a fost anterior arătat, procedând la analiza criticilor din contestația formulată de .. SA, Consiliul reține că autoarea acesteia este nemulțumită de documentația de atribuire elaborată de autoritatea contractantă considerând că în cadrul acesteia au fost introduse cerințe/specificații tehnice nelegale cu rol de restricționare a participării operatorilor economici la procedura de atribuire. Ca o chestiune prealabilă, dată fiind natura litigiului, actul atacat și solicitările adresate Consiliului, soluționarea contestației se va raporta la următoarele dispoziții legale privind achizițiile publice: din Legea nr. 98/2016: - art. 3 alin. (1) lit. rr) - specificațiile tehnice reprezintă cerințe, prescripții, caracteristici de natură tehnică ce permit fiecărui produs, serviciu sau lucrare să fie descris, în mod obiectiv, într-o manieră corespunzătoare îndeplinirii necesității autorității contractante; - art. 154 - Autoritatea contractantă are obligația de a elabora documentația de atribuire care conține toate informațiile necesare pentru a asigura operatorilor economici o informare completă, corectă și precisă cu privire la cerințele achiziției, obiectul contractului și modul de desfășurare a procedurii de atribuire; - art. 155 alin. (6) - Specificațiile tehnice trebuie să permită tuturor operatorilor economici accesul egal la procedura de atribuire și nu trebuie să aibă ca efect introducerea unor obstacole nejustificate față de asigurarea unei concurențe efective între operatorii economici; - 156 alin. (2) – cu excepția cazului în care acest lucru este justificat de obiectul contractului, specificațiile tehnice nu precizează un anumit producător, o anumită origine sau un anumit procedeu care caracterizează produsele sau serviciile furnizate de un anumit operator economic și nici nu se referă la mărci, brevete, tipuri, la o origine sau la o producție specifică, care ar avea ca efect favorizarea sau eliminarea anumitor operatori economici sau produse. din H.G. nr. 395/2016: - art. 20 alin. (10) - Caietul de sarcini conține, în mod obligatoriu, specificații tehnice care reprezintă cerințe, prescripții, caracteristici de natură tehnică ce permit fiecărui produs, serviciu sau lucrare să fie descris, în mod obiectiv, astfel încât să corespundă necesității autorității contractante”. Astfel, raportat la prevederile legale anterior menționate, Consiliul constată că documentația de atribuire trebuie să conțină toate informațiile necesare operatorilor economici interesați de participarea la procedura de atribuire cu privire la cerințele achiziției și modul de Pagina 38 din 95

desfășurare a acesteia, iar prevederile documentației de atribuire nu trebuie să restricționeze, în mod nejustificat, participarea operatorilor economici interesați la procedura de atribuire. Prin urmare, necesitatea sau oportunitatea achiziționării de servicii/lucrări/produse de o anumită performanță, precum și caracteristicile tehnice impuse pentru acestea, sunt stabilite de fiecare autoritate contractantă în parte, în funcție de necesitățile obiective și prioritățile comunicate de compartimentele din cadrul său, însă îi revine acesteia obligația de a justifica atât oportunitatea inițierii procedurii de atribuire cât și stabilirea specificațiilor tehnice, drepturile autorităților contractante la care s-a făcut referire mai sus trebuie exercitate cu bună credință, iar nu cu scopul de a limita sau restricționa accesul la procedură, de natură a restrânge concurența între agenții economici, întrucât s-ar aduce atingere principiilor care stau la baza atribuirii contractului de achiziție publică – nediscriminarea și tratamentul egal. Pe de altă parte, Consiliul are în vedere că prevederile legale aplicabile în materia achizițiilor publice nu obligă autoritatea contractantă să accepte produse care nu corespund necesităților sale, astfel că acesta nu poate fi sancționată pentru refuzul de a nu aduce modificări cerințelor tehnice ori altor prevederi ale documentației, atâta timp cât acestea îi satisfac interesele, achizitoarea fiind singura în măsură să-și stabilească propriile necesități, orice achiziție care nu ar conduce la satisfacerea în mod deplin a nevoilor sale reprezentând o folosire ineficientă a fondurilor. Așadar, modificarea sau cenzurarea caracteristicilor tehnice solicitate poate face obiectul contestării de către operatorii economici interesați în situația încălcării de către autoritate a ipotezelor date de cele două temeiuri de drept citate mai sus (art. 155 alin. (6) și art 156 alin. (2) din legea nr 98/2016). În altă ordine de idei, nu există o prevedere legală care să oblige autoritatea să accepte produse care nu corespund necesităților sale, iar Consiliul nu poate sancționa autoritatea contractantă pentru exercitarea dreptului său de a nu aduce modificări cerințelor tehnice ori altor prevederi ale documentației, atâta timp cât acestea îi satisfac interesele. Autoritatea contractantă este singura în măsură să-și stabilească propriile necesități, orice achiziție care nu ar conduce la satisfacerea în mod deplin a nevoilor sale reprezentând o folosire ineficientă a fondurilor. Prin urmare, necesitatea sau oportunitatea achiziționării de produse/servicii/lucrări de o anumită performanță, precum și caracteristicile tehnice impuse pentru acestea, sunt stabilite de fiecare autoritate contractantă în parte, în funcție de necesitățile obiective și prioritățile comunicate de compartimentele din cadrul său, relevante în acest caz fiind dispozițiile art. 3 din H.G. nr. 395/2016. Curtea de Apel Ploiești, Secția a II-a civilă, de contencios administrativ și fiscal, în decizia nr. . din 12 decembrie 2016, a reținut că Pagina 39 din 95

necesitatea sau oportunitatea unei anumite achiziții este stabilită de fiecare autoritate contractantă, în funcție de necesitățile obiective și particularitățile comunicate de compartimentele din cadrul său. Caietul de sarcini conține, în mod obligatoriu, specificații tehnice care reprezintă cerințe, prescripții, caracteristici de natură tehnică ce permit fiecărui produs, serviciu sau lucrare să fie descris, în mod obiectiv, astfel încât să corespundă necesității autorității. Curtea de Apel Alba Iulia în Decizia nr. . a statuat următoarele: Or, absenţa unei astfel de obligaţii este corectă, întrucât autoritatea contractantă trebuie să evalueze fiecare procedură de achiziţie publică, în parte, şi să aleagă modalitatea de organizare a procedurii aplicabile şi de întocmire a documentaţiei de atribuire, care să asigure cel mai bine atingerea scopului urmărit prin încheierea contractului şi o utilizare cât mai eficientă a fondurilor publice. Fragmentarea obiectului contractului, în vederea asigurării accesului sporit al ofertanţilor la procedură şi libera competiţie dintre aceştia, nu poate constitui singurul deziderat al procedurii de achiziţie publică, autoritatea contractantă fiind aceea care stabileşte, în funcţie de condiţiile concrete, toate detaliile procedurii de atribuire, în scopul realizării unei cât mai eficiente utilizări a fondurilor publice si a satisfacerii intereselor sale. Aşa fiind, în lipsa unor dispoziţii legale exprese şi imperative, revine autorităţii contractante rolul de a asigura un echilibru între interesele sale (în condiţiile în care regula este aceea a priorităţii interesului publice, în dauna celui privat, al operatorilor economici) modalitatea de atingere a acestora - ceea ce presupune stabilirea obiectului contractului, a documentaţiei şi a întregii proceduri de atribuire precum şi respectarea legislaţiei în materia achiziţiilor publice. și Curtea de Apel Oradea în cuprinsul Hotărârii nr. ./15.04.2022 a reținut următoarele considerente: ”Cum autoritatea contractantă îşi cunoaşte cel mai bine nevoile iar principiul libertăţii contractuale implică cerinţa ca acesteia să nu îi fie impusă încheierea unui contract în alte condiţii sau cu privire la alte produse decât are nevoie, Curtea constată că nu se impune modificarea documentaţiei de atribuire în sensul de a solicita ca produsul achiziţionat să poată îndeplini şi funcţia de curăţare, atât timp cât autoritatea contractantă îşi doreşte un astfel de produs. (...) Sub acest aspect, aşa cum s-a arătat anterior, Curtea are în vedere faptul că autoritatea contractantă îşi cunoaşte cel mai bine nevoile, neputând fi obligată să solicite un produs care nu îi satisface nevoile pentru care doreşte să îl folosească”. Din economia celor redate rezultă că regula o reprezintă situația în care necesitatea sau oportunitatea achiziționării la un anumit nivel de performanță, precum și caracteristicile tehnice impuse, sunt stabilite de fiecare autoritate contractantă în parte, în funcție de necesitățile obiective și prioritățile comunicate de compartimentele din cadrul autorității contractante [art. 2 alin. (3) lit. b) și art. 12 alin. (3) lit. a) din H.G. nr. 395/2016]. Singura limitare a acestui drept al autorității contractante este determinată de introducerea unor obstacole nejustificate faţă de asigurarea unei concurenţe efective între operatorii economici, în sfera unei astfel de posibilități aflându-se și situația impunerii de către autoritate a unor specificații și condiții care nu au legătură cu nevoia sa de achiziție. Pagina 40 din 95

În consecință, pentru a cenzura caracteristicile/specificațiile tehnice stabilite de autoritatea contractantă, așa cum solicită petenta în prezenta cauza, este necesară stabilirea existenței, prin ele, a unor condiții restrictive, nejustificate și nelegale ce pot împiedica o concurență efectivă între operatorii economici, precum și a existenței unor specificații care nu contribuie la descrierea, în mod obiectiv, a produselor astfel încât să corespundă necesităţii achizitoarei. Prin urmare, contestatoarea, în susținerea demersului său la Consiliu, are obligația de a proba caracterul restrictiv al cerințelor criticate, prin prezentarea unor mijloace de probă pertinente și concludente, fiind pe deplin aplicabile în acest caz prevederile art. 249 din Codul de procedură civilă, potrivit cărora „cel care face o susținere în cursul procesului trebuie să o dovedească, în afară de cazurile anume prevăzute de lege”. Acestei obligații a contestatorului, de a face proba afirmațiilor sale, îi corespunde obligația autorității contractante de a proba și justifica oportunitatea conținutului documentației de atribuire, astfel că în verificările sale Consiliul va avea în vedere și art. 154 din Legea nr. 98/2016, potrivit căruia „Autoritatea contractantă are obligația de a elabora documentația de atribuire care conține toate informațiile necesare pentru a asigura operatorilor economici o informare completă, corectă și precisă cu privire la cerințele achiziției, obiectul contractului și modul de desfășurare a procedurii de atribuire”, întrucât documentația de atribuire trebuie să conțină toate informațiile necesare operatorilor economici interesați de participarea la procedura de atribuire cu privire la cerințele achiziției și modul de desfășurare a acesteia. Nu în ultimul rând, trebuie subliniat că drepturile autorităților contractante la care s-a făcut referire mai sus trebuie exercitate cu bună credință, iar nu cu scopul de a limita sau restricționa accesul la procedură, de natură a restrânge concurența între agenții economici, întrucât s-ar aduce atingere principiilor care stau la baza atribuirii contractului de achiziție publică – nediscriminarea și tratamentul egal. În consecință, în evaluarea temeiniciei cererilor adresate Consiliului, acesta va avea în vedere faptul că solicitările trebuie justificate și probate obiectiv, cu dovada fermă a caracterului restrictiv, simpla pretindere a necesitații modificării lor și simpla afirmație că restricționează concurența nefiind suficiente pentru a determina nelegalitatea actului atacat. În egală măsură, în stabilirea legalității actului atacat al autorității contractante va fi avută în vedere și proba pe care achizitoarea o realizează cu privire la legătura obiectivă de cauzalitate și dependența dintre specificația criticată și nevoia sa de achiziție. Consiliul va analiza criticile în ordinea în care acestea au fost formulate în contestație pentru o identificare facilă. 1). Prima critică formulată de .. SA (pct. II din contestație) vizează faptul că obiectul achiziţiei nu este în corespondenţă cu codul CPV principal care îl descrie cel mai exact. Pagina 41 din 95

Argumentele aduse de autoarea contestației în favoarea criticii formulate vizavi de modificarea codului CPV reclamat se bazează pe următoarele aspecte: - astfel cum rezultă din Secţiunea nr. II din anunţul de participare şi din fişa de date a procedurii de atribuire, obiectul achiziţiei constă în furnizarea unui "Sistem de e-ticketing necesar pentru îmbunătăţirea transportului public de călători in zona metropolitană Timişoara", care să respecte cerinţele indicate în caietul de sarcini. Prin urmare, obiectul şi scopul principal al achiziţiei este înlocuirea şi modernizarea sistemului de taxare/validare pentru transportul public din zona metropolitană Timişoara, și nu de echipamente de monitorizare a acestuia; - cu toate acestea, atât anunţul de participare,fişa de date şi Ccaietul de sarcini, menţionează drept Cod CPV principal - 34970000-7 Echipament de monitorizare a traficului, o mai exactă corespondenţă dintre obiectul achiziţiei şi Codul CPV principal ar fi asigurată prin raportare la codul CPV 30123100-8 Maşini de validare a biletelor (Rev.2). În sprijinul afirmațiilor sale vizavi de înlocuirea codului CPV principal indicat în documentaţia de atribuire potrivit menţiunilor arătate, pentru a permite informarea corectă a tuturor operatorilor economici care utilizează criteriul codului CPV în căutarea si identificarea procedurilor la care intenţionează să participe, autoarea contestației invocă dispozițiile legale incidente , respectiv art. 16 alin. (3) din HG nr. 395/2016:(2) Obiectul achiziţiei publice se pune în corespondenţă cu codul/codurile CPV care îl descriu cât mai exact, relevantă în acest context fiind activitatea ce caracterizează scopul principal al contractului. Se vor reține și precizările achizitoarei, în replică la cele reclamate, vizavi de caracterul complex şi integrat al achiziţiei, astfel contrar afirmaţiei contestatoarei potrivit căreia obiectul achiziţiei ar fi limitat la „maşini de validare a biletelor", documentaţia de atribuire, în special caietul de sarcini, descrie un sistem informatic complex - o platformă digitală integrată de mobilitate urbană, care include următoarele componente şi funcţionalităţi: • subsisteme de ticketing şi validare a biletelor pentru transportul public; • integrare cu ecranele digitale din staţii şi vehicule; • sistem digital de publicitate în vehicule şi staţii; • integrare cu platforma de management al traficului OMNIA/SWARCO; • funcţionalităţi avansate de tip router/planner pentru călătorii; • tarifare diferenţiată pentru diverse categorii de utilizatori (elevi, studenţi, pensionari); • mecanisme de subvenţionare a diverselor politici publice (transport, evenimente culturale, încălzire centralizată etc.); • back-office cu funcţii de business intelligence şi instrumente de raportare pentru operatorul de transport şi autoritatea contractantă; Pagina 42 din 95

• interoperabilitate şi integrare cu servicii externe (Google Maps, Waze, aplicaţii smart city) prin standardul european FIWARE. Această configuraţie depăşeşte cu mult simpla furnizare de echipamente de validare, proiectul vizând o soluţie tehnologică avansată de management şi monitorizare a mobilităţii metropolitane. De altfel, utilizarea termenului ,,e-ticketing" în titlul proiectului reflectă cerinţele de cofinanţare prin PNRR. Așadar, argumentul decisiv adus de autoritatea contractantă în favoarea netemeiniciei criticii se bazează pe faptul că alegerea codului CPV principal 34970000-7 - Echipament de monitorizare a traficului este conformă cu dispoziţiile legale aplicabile şi reflectă scopul real şi integrat al contractului, iar codul propus de contestatoare – CPV 30123100-8 Maşini de validare a biletelor (Rev.2) este, cel mult, aplicabil ca cod secundar, având în vedere caracterul limitat şi auxiliar al componentelor de validare în structura generală a proiectului. Sintetizând, achizitoarea a concluzionat în respingerea criticii faptul că, în această procedură, scopul principal nu este achiziţia de validatoare, ci implementarea unui sistem integrat de management al mobilităţii urbane şi al transportului public, cu funcţionalităţi extinse de planificare, analiză, control şi interoperabilitate. Prin urmare, alegerea codului 34970000-7 - Echipament de monitorizare a traficului este pe deplin justificată, acesta reflectând fidel scopul complex şi integrat al achiziţiei.

Din economia informațiilor anterior redate din cuprinsul documentației de atribuire, Consiliul determină temeinicia celor susținute de autoritatea contractantă vizavi de caracterul complex şi integrat al achiziţiei, care depăşeşte cu mult simpla furnizare de echipamente de validare, proiectul vizând o soluţie tehnologică avansată de management şi monitorizare a mobilităţii metropolitane, platformă digitală integrată de mobilitate urbană include următoarele componente şi funcţionalităţi: • subsisteme de ticketing şi validare a biletelor pentru transportul public; • integrare cu ecranele digitale din staţii şi vehicule; • sistem digital de publicitate în vehicule şi staţii; • integrare cu platforma de management al traficului OMNIA/SWARCO; • funcţionalităţi avansate de tip router/planner pentru călătorii; • tarifare diferenţiată pentru diverse categorii de utilizatori (elevi, studenţi, pensionari); • mecanisme de subvenţionare a diverselor politici publice (transport, evenimente culturale, încălzire centralizată etc.); • back-office cu funcţii de business intelligence şi instrumente de raportare pentru operatorul de transport şi autoritatea contractantă; • interoperabilitate şi integrare cu servicii externe (Google Maps, Waze, aplicaţii smart city) prin standardul european FIWARE. Pagina 43 din 95

Achizitoarea a explicat că, de altfel, utilizarea termenului e- ticketing în titlul proiectului reflectă cerinţele de cofinanţare prin PNRR. Consiliul reține indicarea la pct. II.1.2 Cod CPV Principal a codului CPV: 34970000-7 Echipament de monitorizare a traficului (Rev.2) Achizitoarea a indicat și coduri CPV secundare în vederea atragerii atenției asupra componentelor specifice ale sistemului integrat de management al mobilităţii urbane şi al transportului public: Coduri CPV secundare: 30123100-8 Masini de validare a biletelor (Rev.2) 30144200-2 Distribuitoare automate de bilete (Rev.2) 30162000-2 Carduri inteligente (Rev.2) 30216130-6 Cititoare de coduri de bare (Rev.2) 30216200-8 Cititoare de carduri magnetice (Rev.2) 30233320-0 Cititoare combinate de carduri inteligente si amprente (Rev.2) 32323400-7 Echipament video de redare (Rev.2) 35125000-6 Sisteme de supraveghere (Rev.2) 48110000-2 Pachete software pentru puncte de vanzare (POS) (Rev.2) 48813000-0 Sisteme de informare a pasagerilor (Rev.2) 51500000-7 Servicii de instalare de echipamente si utilaje (Rev.2) 63712710-3 Servicii de monitorizare a traficului (Rev.2) 64216200-5 Servicii de informare electronica (Rev.2) 72212670-6 Servicii de dezvoltare de software pentru sisteme de operare in timp real (Rev.2) 72212732-9 Servicii de dezvoltare de software pentru securitatea datelor (Rev.2) 72413000-8 Servicii de proiectare de site-uri WWW (World Wide Web) (Rev.2) 72510000-3 Servicii de gestionare informatica (Rev.2. Așa cum a fost anterior reținut, în evaluarea temeiniciei cererilor adresate Consiliului, acesta va avea în stabilirea legalității actului atacat al autorității contractante proba pe care achizitoarea o realizează cu privire la legătura obiectivă de cauzalitate și dependența dintre specificația criticată și nevoia sa de achiziție. Sunt incidente următoarele dispoziții legale incidente: - art. 83 alin. (1) şi (3) din Legea nr. 98/2016: (1) In cuprinsul documentaţiei de atribuire autoritatea contractantă defineşte obiectul achiziţiei prin descrierea necesităţilor autorităţii contractante şi a caracteristicilor solicitate pentru produsele, lucrările sau serviciile care urmează a fi achiziţionate şi stabileşte criteriul de atribuire şi factorii de evaluare a ofertelor. (3) Informaţiile furnizate prin documentaţia de atribuire trebuie să fie suficient de precise pentru a permite operatorilor economici să determine natura şi obiectul general al achiziţiei şi, pe baza acestora, să decidă transmiterea unei solicitări de participare sau neparticiparea la procedura de atribuire. - art. 154 din Legea nr. 98/2016: (1) Autoritatea contractantă are obligaţia de a elabora documentaţia de atribuire care conţine toate informaţiile necesare pentru a asigura operatorilor economici o informare completă, corectă şi precisă cu privire la cerinţele achiziţiei, obiectul contractului şi modul de desfăşurare a procedurii de atribuire. - art. 16 alin. (3) din HG nr. 395/2016: (2) Obiectul achiziţiei publice se pune în corespondenţă cu codul/codurile CPV care îl descriu cât mai exact, relevantă în acest context fiind activitatea ce caracterizează scopul principal al contractului. Pagina 44 din 95

Consiliul are în vedere legislația europeană în materie, respectiv REGULAMENTUL (CE) NR.213/2008 AL COMISIEI din 28 noiembrie 2007, de modificare a Regulamentului (CE) nr. 2195/2002 al Parlamentului European și al Consiliului privind Vocabularul comun privind achizițiile publice (CPV) și a Directivelor 2004/17/CE și 2004/18/CE ale Parlamentului European și ale Consiliului în ceea ce priveşte procedurile de achiziții publice, în ceea ce privește revizuirea CPV, care la art. 1) prevede că „Regulamentul (CE) nr. 2195/2002 a stabilit Vocabularul comun privind achizițiile publice (CPV), un sistem unic de clasificare aplicabil achizițiilor publice, cu scopul de a unifica referințele folosite de entitățile și autoritățile contractante pentru descrierea obiectului achiziției.” Totodată, în actul normativ european se prevede Structura sistemului de clasificare, respectiv „1. CPV cuprinde un vocabular principal și un vocabular suplimentar. 2. Vocabularul principal se bazează pe o structură ramificată de coduri de până la nouă cifre, cărora le corespunde o denumire care descrie produsele, lucrările sau serviciile care reprezintă obiectul contractelor de achiziție.

Codul numeric cuprinde 8 cifre, subdivizate după cum urmează: — diviziuni, identificate prin primele două cifre ale codului (XX000000-Y); — grupe, identificate prin primele trei cifre ale codului (XXX00000-Y); — clase, identificate prin primele patru cifre ale codului (XXXX0000-Y); — categorii, identificate prin primele cinci cifre ale codului (XXXXX000-Y). Fiecare dintre ultimele trei cifre conferă un grad mai mare de precizie în interiorul fiecărei categorii.” Așa cum susține autoritatea contractantă și cum reiese din întreaga documentație de atribuire, codul CPV principal 34970000-7 - Echipament de monitorizare a traficului reflectă scopul real şi integrat al contractului, ceea ce este de interes pentru achizitoare este implementarea unui sistem integrat de management al mobilităţii urbane şi al transportului public, cu funcţionalităţi extinse de planificare, analiză, control şi interoperabilitate, astfel alegerea codului 34970000-7 - Echipament de monitorizare a traficului este justificată, acesta reflectând scopul complex şi integrat al achiziţiei. Mai departe, Consiliul are în vedere că achizitoarea a utilizat și coduri CPV secundare pentru o reflectare corectă a tuturor componentelor sistemului inclusiv cel invocat de contestatoare. Față de modificarea solicitată privind codul propus de contestatoare, CPV 30123100-8 Maşini de validare a biletelor (Rev.2) autoritatea formulează apărări pe care Consiliul le apreciază credibile și concludente: Pentru o reflectare corectă a tuturor componentelor sistemului, autoritatea contractantă a avut în vedere şi coduri CPV secundare, inclusiv cel invocat de contestatoare: 30123100-8 - Maşini de validare a biletelor. Totuşi, acest cod vizează o componentă hardware limitată dintr- un sistem IT mai amplu şi, prin urmare, nu putea fi selectat ca CPV principal, în lipsa unei corespondenţe cu obiectul general al contractului. Reamintim că validatoarele sunt doar una dintre multiplele funcţionalităţi finanţate şi implementate. Ulterior, cu ocazia concluziilor scrise formulate contestatoarea Pagina 45 din 95

reclamă aspecte legate de faptul că, astfel cum rezultă expres din clasificarea CPV (.), codului CPV 34970000-7 îi corespund exclusiv două subcategorii: 34970000-7 Echipament de monitorizare a traficului (Rev.2) 34971000-4 Aparate fotografice de control al vitezei (Rev.2) 34972000-1 Sisteme de masurare a fluxului traficului (Rev.2) - Or, prin raportare la obiectul contractului, astfel cum apare în anunţul de participare/fişa de date, dar mai ales prin raportare la elementele indicate chiar de către Autoritatea contractantă, precum şi alte componente şi funcţionalităţi indicate în documentaţia de atribuire, se poate observa că acestea nu corespund niciunuia dintre Codurile de mai sus. -Este adevărat că în situaţiile în care obiectul contractului este foarte complex, cum este cazul de faţă, corecta încadrare într-un anumit cod CPV presupune raportarea la activitatea ce caracterizează scopul principal al contractului. Or, astfel cum am arătat, în condiţiile în care prin prezenta procedură să urmăreşte achiziţionarea unui sistem de e-ticketing, a cărei componentă principală şi esenţială este componenta de taxare/procesare de plăti, este evident că prin indicarea codului CPV principal corespunzător Echipamentelor de monitorizare a traficului nu se asigură o corelare corectă cu obiectul şi scopul contractului. -În mod categoric nici codul propus de contestatoare (30123100-8 - Maşini de validare a biletelor) nu poate cuprinde întreaga complexitate a obiectului procedurii, dar reflectă mai fidel scopul contractului şi corespunde chiar cu prima componentă precizată de Autoritatea contractantă în Punctul de vedere şi îşi regăseşte echivalent în Caietul de sarcini. Într-adevăr, prezenta procedură are ca obiect achiziţionarea a unor echipamente instalate în vehicule de transport public, precum şi aplicaţii software pentru vânzare bilete de transport public, planificare calatorii, informare pe panouri, toate fiind destinate transportului public. -Esenţial este ca Autoritatea contractantă să aleagă un cod CPV principal care să permită o informare corectă tuturor operatorilor economici interesaţi să participe, cu înlăturarea riscului ca, de exemplu, potenţialii participanţi care urmăresc organizarea procedurilor după criteriul codului CPV principal să nu aibă cunoştinţă de procedură. -Pentru aceste motive, solicităm onoratului Consiliu să pună în vedere Autorităţii contractante să adopte măsuri de remediere în sensul înlocuirii codului CPV principal indicat în documentaţia de atribuire potrivit menţiunilor de mai sus, pentru a permite informarea corectă a tuturor operatorilor economici care utilizează criteriul codului CPV în căutarea si identificarea procedurilor la care intenţionează să participe. Și față de aceste susțineri, autoritatea formulează apărări a căror temeinicie este reținută de Consiliu ca fiind judicioasă: - Sistemul este complex şi multidisciplinar, motiv pentru care un singur cod CPV nu poate surprinde exhaustiv toate componentele. De aceea, CPV urile secundare completează descrierea. - Argumentul că „din cauza complexităţii, CPV ul principal ar fi greşit" nu este logic. Complexitatea si diversitatea de componente mostenite din alte proiecte anterioare justifică utilizarea CPV urilor secundare, nu schimbarea scopului principal. - Faptul că anumite componente nu se „închid" perfect în codul principal nu este o neconformitate; pentru acestea există CPV uri secundare. - Conform normelor aplicabile, CPV-ul principal reflectă finalitatea. Restul elementelor sunt gestionate prin CPV uri secundare şi prin specificaţiile tehnice din caiet. Aşadar, abordarea autoritatii contractante este regulamentară şi corectă. - Contestatoarea critică alegerea codului CPV principal, susţinând că ar fi trebuit utilizat exclusiv codul aferent „maşinilor de validare a biletelor". Această abordare este însă una reductivă şi, în mod evident subiectivă. Documentaţia de atribuire descrie un proiect complex de mobilitate urbană inteligentă, care include nu doar validatoare, ci şi componente hardware diverse, platforme software, servicii de integrare, interoperabilitate cu alte sisteme publice şi standarde europene precum FIWARE şi SynchroniCity. În aceste condiţii, alegerea unui cod CPV îngust, care să reflecte doar o mică parte din obiect, ar fi fost înşelătoare şi ar fi restrâns artificial percepţia asupra obiectului achiziţiei. Prin urmare, Autoritatea contractantă a optat pentru un cod CPV principal generic şi reprezentativ, capabil să acopere întreaga complexitate a proiectului. În plus, a Pagina 46 din 95

publicat o listă generoasă de CPV- uri secundare, tocmai pentru a asigura că operatori economici din domenii cât mai diverse vor fi notificaţi prin motoarele de căutare CPV ale platformei SEAP. În concluzie, actuala alegere a CPV-urilor nu numai că este justificată, dar serveşte principiilor transparenţei şi accesului larg la procedură, conform Legii nr. 98/2016. Constatându-se faptul că obiectivul acestei achiziţii este: -integrarea coerentă a componentelor digitale livrate anterior în mod fragmentat; -construirea unei arhitecturi deschise, scalabile şi interoperabile; -asigurarea securităţii cibernetice şi a sustenabilităţii investiţiilor, așa cum a argumentat și achizitoarea, având în vedere că sistemul este complex şi multidisciplinar, motiv pentru care un singur cod CPV nu poate surprinde exhaustiv toate componentele. Astfel, CPV-urile secundare completează descrierea, fiind de interes faptul că respectivele coduri CPV indicate asigură o descriere completă a proiectului. Or, câtă vreme așa cum a susținut inclusiv contestatoarea, că respectivul cod indicat, 30123100-8 Maşini de validare a biletelor (Rev.2) (în vederea solicitării modificării codului CPV principal consemnat în documentele achiziției) nu reflectă în integralitate scopul (În mod categoric nici codul propus (30123100-8 - Maşini de validare a biletelor) nu poate cuprinde întreaga complexitate a obiectului procedurii, dar reflectă mai fidel scopul contractului şi corespunde chiar cu prima componentă precizată de Autoritatea contractantă în Punctul de vedere şi îşi regăseşte echivalent în Caietul de sarcini. Într-adevăr, prezenta procedură are ca obiect achiziţionarea a unor echipamente instalate în vehicule de transport public, precum şi aplicaţii software pentru vânzare bilete de transport public, planificare calatorii, informare pe panouri, toate fiind destinate transportului public) nu se poate susține că modalitatea în care achizitoarea a identificat codurile CPV nu permite informarea corectă a tuturor operatorilor economici care utilizează criteriul codului CPV în căutarea ți identificarea procedurilor la care intenţionează să participe. Mai mult, codul CPV principal stabilit de achizitoare nu este de natură să vatăme societatea contestatoare, accesul operatorilor economici nu a fost restricţionat, procedura a fost publicată în SEAP şi, conform normelor aplicabile, a fost vizibilă la nivel naţional şi european. Complexitatea proiectului, natura finanţării şi conţinutul caietului de sarcini asigură vizibilitate pentru toţi operatorii interesați. În ceea ce priveşte impactul codului CPV asupra participării, se constată că titlul şi descrierea procedurii sunt clare şi reflectă corect obiectul achiziţiei Sistem de e-ticketing pentru transport public metropolitan, alegerea codului CPV principal nu a limitat accesul real al pieţei, deoarece operatorii specializaţi în sisteme de ticketing, mobilitate urbană, soluţii IT şi echipamente de transport au putut identifica şi accesa procedura. De asemenea, utilizarea codurilor CPV secundare a contribuit la asigurarea transparenţei şi a unei descrieri complete a achiziţiei. În consecință, Consiliul constată caracterul nefondat al solicitării, aceasta urmând a fi respinsă și va menține codul principal indicat în Pagina 47 din 95

documentația de atribuire.

2) Referitor la cea de-a doua critică (pct. III.1.1.)se are în vedere că aceasta vizează Subsecţiunea 4.2.7.1 "Inception Report" si "Analiza- Proiectare" în referire la de 2 aspecte, respectiv autoritatea contractantă solicită operatorilor economici participanţi ca, în cadrul propunerilor tehnice, să integreze: - pe de o parte, realizarea prealabilă a rapoartelor "Inception Report"si "Analiza-Proiectare" şi - pe de altă parte, o probă practică/demo/sesiune demonstrativă, care va viza toate funcţionalităţile indicate în caietul de sarcini, contestatoarea apreciind că cele două cerinţe încalcă principiului proporţionalităţii şi imperativele legate de nerestricţionatei abuzivă a concurenţei. Argumentele aduse în favoarea criticii aduse vizavi de realizarea prealabilă a rapoartelor "Inception Report"si "Analiza-Proiectare" se bazează pe următoarele aspecte: Astfel cum rezultă din dispoziţiile Caietului de sarcini, scopul acestor rapoarte este de a "descrie/documenta modalitatea de integrare intre sisteme precum si cu sistemele externe solicitate ". Vă rugăm să constataţi că o asemenea cerinţă este excesivă prin raportare la etapa de elaborare a ofertelor, în condiţiile în care aceste rapoarte presupun o înţelegere aprofundată a tuturor sistemelor, aplicaţiilor si echipamentelor existente, a interfeţelor şi a modului în care acestea schimbă date cu sistemul ofertat în cadrul prezentului proiect. Pentru o descriere corespunzătoare a modalităţii de integrare între sisteme, respectiv cu sistemele externe, este absolut necesar accesul la documentaţia tehnică completă, la echipamente şi la factorii de decizie, care se obţine doar după atribuirea contractului, către ofertantul desemnat câştigător. În etapa de formulare a propunerilor tehnice, ofertanţii nu au acces la informaţiile detaliate despre sistemele cu care trebuie să se realizeze integrarea, împrejurare confirmată chiar de menţiunile din Caietul de Sarcini (a se vedea Secţiunea 5.4.6., p. 45): "Sistemul ERP al STPT este ASSIS iar detaliile cu privire la modul de integrare cu acesta vor fi furnizate câştigătorului licitaţiei". Concluzia la care ajunge contestatoarea este aceea că solicitarea adresată operatorilor economici, încă din etapa de elaborare a ofertei, de a descrie şi documenta în cele două rapoarte "modalitatea de integrare intre sisteme precum si cu sistemele externe solicitate" este disproporţionată, în condiţiile în care o asemenea cerinţă nu poate fi îndeplinită fară acces la informaţiile detaliate despre sistemele cu care trebuie să se realizeze integrarea. În replică la cele susținute de contestatoare autoritatea contractantă a explicat că solicitarea acestor rapoarte în etapa de ofertare este justificată de natura complexă a proiectului şi urmăreşte evaluarea capacităţii metodologice a ofertantului de a propune o soluţie coerentă de integrare a sistemelor solicitate.

Astfel, solicitarea acestor rapoarte este proporţională, fundamentată tehnic şi legal, şi nu restricţionează accesul operatorilor economici cu experienţă relevantă, respectiv: Pagina 48 din 95

- asigură comparabilitatea ofertelor, prin impunerea unei structuri unitare şi evitarea abordărilor arbitrare; - reprezintă o practică uzuală în proiectele IT complexe, în special atunci când sunt implicate tehnologii consacrate (ex: Mifare, NFC, QR, FIWARE, ERP); - permite autorităţii contractante să evalueze modul în care ofertanţii îşi fundamentează planificarea şi alocarea resurselor în mod realist şi coerent; - nu presupun accesul complet la informaţii detaliate, ci doar capacitatea de a propune o arhitectură şi o metodologie iniţială, pe baza cerinţelor generale furnizate în documentaţie; - reflectă o practică deja validată în cadrul altor proiecte similare derulate de Primăria Municipiului Timişoara, cu rezultate pozitive (ex: portal unic, GIS, automatizare fluxuri interne). Cerința reclamată se regăsește astfel consemnată la nivelul caietului de sarcini: 4.2.6 Alte cerinţe 4.2.7.1 "Inception Report" si "Analiza-Proiectare" Având in vedere complexitatea proiectului, multitudinea de integrări si cerinţe, ofertantul va trebui sa realizeze la început "Inception Report" si "Analiza-Proiectare" si sa prezinte rezultatele pentru realizarea celei mai bune soluţii si a unei oferte competitive si bine fundamentata, inclusiv tipurile de training necesare. Totodată, se va tine cont ca se doreşte funcţionarea paralela, a ambelor sisteme, si cel vechi si cel nou, nu se accepta oprirea vechiului sistem pentru punerea in funcţiune a celui nou. Si acest aspect va fi tratat in "Inception Report" si "Analiza-Proiectare" oferindu-se o soluţie ce va fi acceptata de beneficiar. Se va tine cont de faptul ca se doreşte aplicarea unei politici "park & ride". In cadrul acestor rapoarte, se va descrie/documenta modalitatea de integrare intre sisteme precum si cu sistemele externe solicitate. Toate funcţionalităţile din acest caiet de sarcini se vor demonstra de către ofertanţi la o proba practica, care va face parte din etapa evaluării tehnice a ofertelor, la invitaţia autorităţii contractante. Totodată, având în vedere faptul că se doreşte un standard deschis de interconectare a tuturor sistemelor ITS din platforma de mobilitate, pentru toate echipamentele montate de către ofertant (care respectă standardele deschise susţinute de către ItxPT) se va oferi toată documentaţia de instalare / mentenanţă / interconectare / integrare cu sistemele de e- Ticketing care sunt deja montate pe vehiculele in curs de achiziţie si se va oferi asistenţă pentru integrarea lor în sistemul principal de e- Ticketing, fără costuri suplimentare. Din lecturarea cerințelor cuprinse în caietul de sarcini, Consiliul reține următoarele atribuții trasate în sarcina ofertanților, respectiv: - 4 Arhitectura sistemului, recomandări si cerinţe generale 4.1 Definiţii, principii şi constrângeri pentru arhitectura sistemului Prin arhitectura sistemului informatic înţelegem structurile, mecanismele şi interfeţele utilizate, precum şi comunicarea între părţile componente. Arhitectura de sistem descrie viziunea fizică şi logică a sistemului propus, relevă modul în care sistemul va fi construit, defineşte modul în care vor fi utilizate diferite concepte, cât şi aspecte vizând posibilitatea dezvoltării viitoare a sistemului. (...) La proiectarea, realizarea şi implementarea componentelor sistemului aflate în scopul prezentului proiect trebuie să se ţină cont de următoarele principii generale: • Principiul legalităţii: care presupune crearea şi exploatarea sistemului informatic în conformitate cu legislaţia naţională si a UE în vigoare şi a normelor şi standardelor internaţionale recunoscute în domeniu; Pagina 49 din 95

• Principiul modularizării si divizării arhitecturii pe nivele: constă în proiectarea independentă a componentelor sistemului în conformitate cu standardele de interfaţă dintre nivele;

• Principiul arhitecturii bazate pe servicii (SOA - service oriented architecture): constă în distribuirea funcţionalităţii aplicaţiilor în unităţi mai mici, distincte - numite servicii - care pot fi distribuite într-o reţea şi pot fi utilizate împreună pentru a crea aplicaţii destinate implementării funcţiilor de business ale sistemului informatic; • Principiul datelor sigure: stipulează introducerea sau citirea datelor în/din sistem doar prin canalele autorizate, autentificate si criptate; • Principiul disponibilităţii serviciilor: arhitectura software, hardware si de acces la reţele publice trebuie sa fie realizata in aşa fel încât sa ofere mecanisme superioare de redundanta, eliminarea oricăror elemente de tip „punct unic de defecţiune/single point of failure" pentru a atinge o disponibilitate a serviciilor de cel puţin 99,95%. • Principiul restaurării funcţionării in caz de dezastru: arhitectura soluţiei cu model hibrid trebuie sa asigure restaurarea rapida a funcţionării platformei in caz de dezastru, având posibilitatea de a balansa execuţia serviciilor din ambele locaţii - cloud public si , daca se furnizează si serviciile unui datacenter de pe teritoriul României - si de a asigura replicarea consistenta si frecventa a datelor intre aceste locaţii. • Principiul portabilităţii datelor: platforma trebuie sa poată fi migrata intre DataCenter tip cloud (publice sau private), sa conţină toate elementele necesare relocării acesteia in caz de nevoie. • Principiul securităţii informaţionale: presupune asigurarea unui nivel adecvat de integritate, selectivitate, accesibilitate şi eficienţă pentru protecţia datelor de pierderi, alterări, deteriorări şi de acces nesancţionat. • Principiul transparenţei: presupune proiectarea şi realizarea conform principiului modular, cu utilizarea standardelor transparente în domeniul tehnologiilor informatice şi de telecomunicaţii; • Principiul expansibilităţii: stipulează posibilitatea extinderii şi completării sistemului informatic cu noi funcţii sau îmbunătăţirea celor existente; • Principiul scalabilităţii: presupune asigurarea unei performanţe constante a soluţiei informatice la creşterea volumului de date, extinderea funcţionalităţii şi a solicitării sistemului informatic; • Principiul simplităţii şi comodităţii utilizării: presupune proiectarea şi realizarea tuturor aplicaţiilor, mijloacelor tehnice şi de program accesibile utilizatorilor sistemului, bazate pe principii exclusiv vizuale, ergonomice şi logice de concepţie. In termeni tehnici, aceasta înseamnă o experienţă buna de UX (user experience); • Principiul integrităţii, plenitudinii şi veridicităţii datelor: presupune implementarea mecanismelor care permit păstrarea conţinutului şi interpretării univoce a datelor în condiţiile unor influenţe accidentale şi eliminării fenomenelor de denaturare sau lichidare accidentală a acestora, furnizarea unui volum de date suficient executării funcţiilor de business al sistemului informatic şi asigurarea unui grad înalt de corespundere a datelor cu starea reală a obiectelor pe care (...) Așa cum a fost anterior reținut, obiectivul achiziţiei constă în: - integrarea coerentă a componentelor digitale livrate anterior în mod fragmentat; - construirea unei arhitecturi deschise, scalabile şi interoperabile; - asigurarea securităţii cibernetice şi a sustenabilităţii investiţiilor. Potrivit cerințelor documentației se solicită și proiectarea, realizarea şi implementarea componentelor sistemului informatic complex, o platformă digitală integrată de mobilitate urbană. Analizând modalitatea de elaborare privind cerințele reclamate, Consiliul constată că achizitoarea dorește de la operatorii economici să facă dovada înțelegerii obiectului contractului care presupune un sistem Pagina 50 din 95

informatic complex - o platformă digitală integrată de mobilitate urbană, care include o serie de componente şi funcţionalităţi extinse de planificare, analiză, control şi interoperabilitate, care implică pe de o parte, funcţionarea paralelă, a ambelor sisteme, si cel vechi si cel nou, iar pe de altă parte implică de integrare intre sisteme precum si cu sistemele externe solicitate în vederea ofertării unei soluții tehnologică avansată de management şi monitorizare a mobilităţii metropolitane, astfel solicitarea descrierii în cadrul rapoartelor a modalității de integrare este firească. Având în vedere că scopul solicitării respectivelor rapoarte reclamate în etapa de ofertare este justificată de natura complexă a proiectului şi urmăreşte evaluarea capacităţii metodologice a ofertantului de a propune o soluţie coerentă de integrare a sistemelor solicitate (modalitatea de integrare intre sisteme precum si integrarea cu sistemele externe solicitate fiind parte din obiectul contarctului de achiziție) pe de o parte, și, pe de altă parte, așa cum a argumentat și achizitoarea, elaborarea respectivelor rapoarte nu presupun accesul complet la informaţii detaliate, ci doar capacitatea de a propune o arhitectură şi o metodologie iniţială, pe baza cerinţelor generale furnizate în documentaţie și de asemenea că solicitarea rapoartelor reflectă o practică deja validată în cadrul altor proiecte similare derulate de Primăria Municipiului Timişoara, cu rezultate pozitive (ex: portal unic, GIS, automatizare fluxuri interne), Consiliul va respinge solicitarea contestatoarei privind eliminarea respectivelor rapoarte. Contestatoarea reclamă faptul că ofertanţii nu au acces la informaţiile detaliate despre sistemele cu care trebuie să se realizeze integrarea, iar aceste rapoarte presupun o înţelegere aprofundată a tuturor sistemelor, aplicaţiilor si echipamentelor existente, a interfeţelor şi a modului în care acestea schimbă date cu sistemul ofertat în cadrul prezentului proiect. Or, așa cum a susținut autoritatea contractantă, elaborarea respectivelor rapoarte nu presupun accesul complet la informaţii detaliate, ci doar capacitatea de a propune o arhitectură şi o metodologie iniţială, pe baza cerinţelor generale furnizate în documentaţia de atribuire. Autoritatea contractantă a pus la dispoziţia ofertanților datele disponibile necesare formulării unei oferte competitive, iar pentru detalierea soluţiei, este necesară realizarea unor analize proprii de către ofertanți, astfel că achizitoarea nu se poate substitui operatorilor economici în propunerea de soluții tehnice pentru că ar putea fi percepută ca o constrângere și favorizare a participării. Autoarea contestației reclamă aspecte legate de faptul că ofertanţii nu au acces la informaţiile detaliate despre sistemele cu care trebuie să se realizeze integrarea, iar aceste rapoarte presupun o înţelegere aprofundată a tuturor sistemelor, aplicaţiilor și echipamentelor existente, Pagina 51 din 95

a interfeţelor şi a modului în care acestea schimbă date cu sistemul ofertat în cadrul prezentului proiect. Ori, niciunde contestatoarea nu menționează care sunt informațiile detaliate a căror pretinsă lipsă este reclamată. Împrejurarea că prin solicitarea de a descrie în ofertă soluţia de integrare ("Inception Report" şi "Analiza-Proiectare") nu este de natură a conduce la nelegalitatea solicitării elaborării respectivelor rapoarte în etapa de ofertare, pe considerentul că autoritatea contractantă cere de fapt proiectarea tehnică încă din etapa de ofertare, solicitând practic ofertanţilor să prezinte o soluţie finală, detaliată, fără a le fi oferite informaţiile absolut necesare pentru a o construi. Deopotrivă de valide sunt și apărările aduse de autoritatea contractantă față de susținerile contestatoarei vizavi de nelegalitatea solicitării elaborării respectivelor rapoarte în etapa de ofertare: Conform art. 155 din Legea nr. 98/2016, specificaţiile tehnice pot viza inclusiv procese de analiza prin proiectare la nivel inalt sau propuneri de arhitectura a sistemului final. „Inception Report" şi „Analiză Proiectare" sunt instrumente de fundamentare tehnică pentru propunerea unei arhitecturi de sistem acceptabile care sa duca la integrarea corectă cu infrastructura existentă - o practică uzuală în achiziţii complexe. Ele nu impun implementare, ci demonstrarea capacităţii de înţelegere şi proiectare in termeni de nivel inalt si de arhitectura. Sunt conforme cu considerentul (74) al Directivei 2014/24/UE, şi încurajează cerinţe funcţionale şi de performanţă pentru a evita favorizarea unor soluţii unice. Cerinţa este proporţională şi necesară. In plus, prin clarificarile si informatiile obtinute in urmat acestor etape, ele sunt si un suport pentru Furnizor in dezvoltarea ulterioara a solutiei. Elaboararea acestor documente este totodata si in interesul Furnizorului deoarece evita neintelegerile ulterioare si servesc ca baza de validare a solutiei inainte de a trece la fazele majore de implementare a Proiectului Așa cum a argumentat și achizitoarea în această etapă prin solicitarea rapoartelor în discuție nu se solicită implementarea soluției tehnice, ci demonstrarea capacităţii de înţelegere şi proiectare in termeni de nivel inalt si de arhitectura. Cerinţa privind prezentarea unui Inception Report şi a unei Analiză-proiectare nu echivalează cu executarea parţială a contractului. Cu alte cuvinte ceea ce prezintă interes pentru autoritatea contractantă prin solicitarea Inception Report şi a unei Analiză- proiectare este proba faptului că ofertanţii îşi dovedesc capacitatea de a înţelege şi integra cerinţele, aceste documente reduc riscul unor neînțelegeri ulterioare, ele servind ca baza de validare a soluției de către beneficiar inainte de a trece la fazele urmatoare ale proiectului. Prin solicitarea repectivelor rapoarte, Consiliul determină că autoritatea contractantă a acordat o atenție sporită vizavi de evaluarea capacităţii metodologice a ofertantului de a propune o soluţie coerentă de integrare a sistemelor solicitate. Cu alte cuvinte, se solicită dovada înțelegerii de către ofertanți a obiectului contractului, respectiv capacitatea de a propune o arhitectură şi o metodologie iniţială, pe baza cerinţelor generale furnizate în documentaţie. Un alt argument adus de contestatoare în favoarea nelegalității respectivelor rapoarte în etapa de ofertare se bazează pe faptul că, prin Pagina 52 din 95

acceptarea unor propuneri generice în faza de ofertare, beneficiarul îşi asumă un risc considerabil. Astfel contestatoarea susține nelegalitatea rapoartelor și pe considerentul că soluţia propusă de ofertantul câştigător s-ar putea dovedi ulterior a fi imposibil de implementat sau mult mai costisitoare, odată ce detaliile tehnice reale devin cunoscute. Tocmai de aceea, elaborarea acestor rapoarte în faza de execuţie a contractului ar asigura o planificare mult mai realistă şi ar proteja interesul beneficiarului, permiţând o soluţie optimă. Practic contestatoarea se prevalează de pretinsa nelegalitate a solicitării respectivelor rapoarte în etapa de ofertare, pe considerentul că aceste rapoarte sunt aferente etapei de derulare a contractului pentru a-i reproșa achizitoarei faptul că o astfel de cerinţă conduce inevitabil la documente formale, realizate pe baza unor presupuneri nevalidate şi, implicit, cu valoare practică redusă. Faptul că autoritatea contractantă solicită informații concrete prin care ofertanţii îşi dovedesc capacitatea de a înţelege şi integra cerinţele, documentele cerute reprezintă proiectare la nivel de concept şi integrare pe baza informaţiilor din caiet şi a know how ului ofertantului, astfel că cerinţa de a prezenta „Inception Report" şi „Analiză- Proiectare" nu echivalează cu executarea parţială a contractului, ci este o practică uzuală în proiectele digitale complexe, prin care ofertanţii dovedesc înţelegerea cerinţelor şi fezabilitatea integrării, conduita adoptată de autoritatea contractantă fiind în concordanță cu atribuțiile acesteia de achizitor, una dintre acestea fiind stabilirea nivelului calitativ ce trebuie realizat prin execuţie pe baza reglementărilor tehnice. Sunt juste susținerile contestatorei precum că detalierea tehnică finală se definitivează în etapa de implementare, conform HG nr. 907/2016, însă la fel de judicioase sunt și argumentele achizitoarei potrivit cărora „Inception Report" şi „Analiza de proiectare" aparţin etapei de pregătire şi nu echivalează cu implementarea. Ele fundamentează inclusiv cererea de finanţare, fără a reprezenta execuţie. Conform legislaţiei (Legea nr. 98/2016; HG nr. 395/2016, Secţiunea a 4 a, Art. 20 lit. b), caietul de sarcini trebuie să includă cerinţele tehnice şi livrabilele obligatorii. În plus, art. 54 alin. (4) din Legea nr. 98/2016 permite stabilirea unor condiţii specifice justificate şi proporţionale. Art. 155 confirmă că specificaţiile pot viza procese/metode relevante pe ciclul de viaţă. Cerinţele sunt proporţionale cu valoarea şi complexitatea contractului. În chiar materialul contestatoarei (pct. 28) se recunoaşte că proiectarea tehnică include cele două rapoarte. Aceste document sunt documente standard in proiectele de solutii complexe de IT care au rolul de a confirma ca toate partile implicate sunt aliniate pe obiective, livrabile, metodologie, etc. (..) Sunt livrabile de proiectare/fundamentare premergătoare execuţiei, conform cu art. 155 din Legea 98/2016 si reprezinta caracteristici privind procese şi metode pe ciclul de viaţă. Ele nu transferă riscuri nejustificate şi nu restrâng concurenţa. Recapitulând ansamblul considerentelor anterior expuse Consiliul reține următoarele aspecte: Pagina 53 din 95

- autoritatea contractantă nu solicită cod sursă sau implementare, ci documente de planificare pe baza know-how-ului deținut, livrabilele solicitate asigură că ofertele sunt realiste, comparabile şi bazate pe o fundamentare tehnică, reducând riscul unor soluţii nefezabile; - contrar celor susținute de contestatoare, potrivit cărora rapoarte sunt livrabile de execuţie, respectivele rapoarte sunt livrabile de proiectare/fundamentare premergătoare execuţiei; - nu este necesar acces complet la sistemele existente pentru nivelul de proiectare solicitat. Documentele solicitate reprezintă proiectare la nivel de concept şi integrare pe baza informaţiilor din caiet şi a know-how ului ofertantului. În raport de cele mai sus reținute se constată caracterul nefondat al solicitării, aceasta urmând a fi respinsă. Aceeași concluzie de netemeinicie va fi reținută de Consiliu și în ceea ce privește pretinsa nelegalitate a solicitării unei probe practice /demo/sesiune demonstrativă, care va viza toate funcţionalităţile indicate în caietul de sarcini (pct. III.1.2. din contestație) din considerentele mai jos expuse. Contestatoarea susține în argumentarea retricitivității solicitării de probe practice/sesiuni demonstrative/demo-uri faptul că, având în vedere principiul proporţionalităţii, precum şi imperativul instituit de legislaţia achiziţiilor publice ca cerinţele/specificaţiile tehnice să permită tuturor operatorilor economici accesul egal la procedura de atribuire şi să nu aibă ca efect introducerea unor obstacole nejustificate faţă de asigurarea unei concurenţe efective, solicitarea unei sesiuni demonstrative în cadrul contractelor pentru achiziţia de sisteme IT ar trebui să fie o soluţie excepţională, iar achizitoarea ar fi trebuit să justifice solicitarea unei sesiuni demonstrative din perspectiva oportunităţii şi necesităţii acestei solicitări, inclusiv prin raportare la oportunitatea resurselor de timp şi de bani care ar urma să fie consumate de către ofertanţi şi impactul probabil al acestora asupra nivelului de concurenţă. Mai departe, contestatoarea enumeră principalele motive pentru care se impune excluderea cerinţei privind proba practică, respectiv: - pregătirea unei sesiuni demonstrative este de natură a aduce costuri semnificative suplimentare ofertanţilor, acestea crescând cu cât cerinţele pentru sesiunea demonstrativă vizează aplicaţii software care nu sunt disponibile deja pe piaţă sau funcţionalităţi care nu există deja la aplicaţii disponibile pe piaţă (aplicaţia respectivă nu este de tip .. - Commercial Of The Shelf, cum este cazul celor mai multe componente din Sistemul de e- ticketing care face obiectul prezentei achiziţii); - în al doilea rând, solicitarea unei sesiuni demonstrative pentru aplicaţii de tip .. personalizat sau la comandă (chiar şi pentru părţi din acestea) echivalează cu solicitarea către ofertanţi de a executa total sau parţial viitorul contract de manieră anticipată la nivelul ofertei. O astfel de situaţie este Pagina 54 din 95

excesivă şi contra înţelesului comun care poate fi atribuit diferenţei dintre, de o parte, procesul de ofertare şi ce înseamnă propunerea tehnică şi, pe de altă parte, procesul de execuţie a contractului ca atare. într-adevăr, caietul de sarcini include în mod expres activităţi de dezvoltare şi integrare, care prin natura lor nu pot fi demonstrate în cadrul unei sesiuni de probă practică la momentul ofertării; - în al treilea rând, această cerinţă este de natură a limita în mod direct numărul operatorilor economici interesaţi de transmiterea unei oferte la cei care sunt dispuşi să îşi asume, în plus faţă de costurile administrative obişnuite ale ofertării, şi pe cele medii spre mari ale pregătirii unei aplicaţii software sau funcţionalităţi la o aplicaţie software de la "0" sau la cei care s-au pregătit anticipat pentru aplicaţia software respectivă, cu încălcarea prevederilor art. 50 şi 155 alin. (6) din Legea nr. 98/2016, anterior citate (având ca efect restrângerea nejustificată a concurenţei); -

în

plus,

cerinţa

încalcă

în

mod

direct

principiul nediscriminării/tratamentului egal, întrucât poate favoriza în mod nejustificat anumiţi operatori economici, respectiv pe aceia care au deja produse implementate în mod identic; - în al patrulea rând, legislaţia în domeniul achiziţiilor publice impune ca verificarea capacităţii tehnice ale unui ofertant de a realiza viitorul contract să se facă prin cerinţe de calificare legate de acest aspect rezultând că nu se poate invoca de către Autoritatea contractantă nevoia de a verifica suplimentar capacitatea tehnică a unui ofertant prin alte cerinţe care nu sunt cerinţe de calificare. în plus, autoritatea contractantă nu are dreptul de a utiliza factori de evaluare care să conducă la o libertate de apreciere nelimitată şi trebuie să asigure o concurenţă reală între operatorii economici; - în al cincilea rând, precizăm că toate aceste motive care impun Autorităţii contractante să nu solicite în mod abuziv o sesiune demonstrativă/probă practică, au fost reţinute de către Agenţia Naţională pentru Achiziţii Publice în cadrul îndrumării privind adecvarea solicitărilor de sesiuni demonstrative/demo-uri ca parte din propunerea tehnică în cadrul contractelor pentru achiziţia de sisteme IT (a se vedea Anexa nr. 4) în cadrul acestei îndrumări, se menţionează în mod expres şi că: "Sesiuni demonstrative nu pot fi cerute pentru aplicaţii software .. personalizat (pentru funcţionalităţile care ar urma să fie personalizate în timpul execuţiei contractului) sau software la comandă pentru că ar echivala cu o obligaţie oneroasă pentru ofertanţi, egală cu execuţia totală sau parţială a viitorului contract şi conduce la creşterea costurilor administrative şi a duratei procesului de achiziţie publică. În plus, este de reţinut că dezvoltarea unor aplicaţii software .. personalizat sau la comandă presupune parcurgerea sistematică şi documentată a tuturor etapelor de realizare a unui sistem IT, activitate care nu se poate realiza anticipat de către ofertant fără să beneficieze de interacţiunea de lucru cu autoritatea contractantă şi obişnuitul proces iterativ între cele două părţi în definirea clară, de detaliu a nevoilor/aşteptărilor." - Or, astfel cum am precizat şi cum rezultă din documentaţia de atribuire, Sistemul de e-ticketing care face obiectul procedurii de atribuire cuprinde în cea mai mare parte exact astfel de componente de software personalizat, acesta nefiind un produs IT de tip ... - De altfel, chiar şi în cazul în care Sistemul ofertat ar fi fost un produs IT de tip .., autoritatea contractantă avea oricum obligaţia de justifica alegerea Pagina 55 din 95

includerii acestei cerinţe, prin raportare la costurile suportate de ofertanţi. Potrivit îndrumării ANAP: "Sesiunile demonstrative pot fi solicitate doar în cazul produselor IT de tip .. pentru că în acest caz solicitarea nu ar aduce costuri relevante ofertanţilor având în vedere că produsele respective există deja pe piaţă şi în portofoliul lor. În plus, pregătirea sesiunii demonstrative nu ar fi de natură să consume resurse importante de timp care să facă necesară prelungirea în mod relevant peste termenele minime a perioadei de depunere a ofertelor. Chiar dacă sesiunea demonstrativă ar fi pentru un produs .., autoritatea contractantă tot trebuie să justifice alegerea acestui instrument". Față de susținerile și argumentele aduse de contestatoare, autoritatea formulează apărări pe care Consiliul le apreciază edificatoare și concludente: Solicitarea unei demonstraţii practice este pe deplin justificată de complexitatea tehnică şi valoarea ridicată a contractului, care implică: - dezvoltarea de componente software personalizate; - integrarea cu infrastructura existentă (OMNIA/SWARCO, ecrane, semafoare etc.); - interoperabilitate cu aplicaţii şi servicii smart city, inclusiv conform standardului FIWARE. Proba demo: - permite evaluarea capacităţii reale de implementare a soluţiei ofertate; - reduce riscul atribuirii unui contract neimplementabil, contribuind la protejarea fondurilor publice; - nu restrânge competiţia, întrucât se aplică în mod egal tuturor ofertanţilor, care sunt evaluaţi pe baza aceloraşi cerinţe funcţionale; - este proporţională cu miza proiectului, iar eventualele costuri de pregătire a unei prezentări tehnice sunt inerente participării la o procedură de achiziţie cu grad ridicat de dificultate tehnică. Concluzia la care ajunge achizitoarea este aceea că Îndrumarea ANAP este orientativă şi nu interzice probele practice, solicitarea probei demonstrative este justificată, transparentă şi nediscriminatorie şi ţine cont de concluziile şi recomandările ANAP din Îndrumarea privind adecvarea solicitărilor de sesiuni demonstrative /demo-uri, ca parte din propunerea tehnică în cadrul contractelor pentru achiziţia de sisteme IT care prevăd: ( ...) recomandăm următoarele reguli de interpretare/tratare a solicitărilor privind sesiunile demonstrative: - Sesiunile demonstrative pot fi solicitate doar în cazul produselor IT de tip .. pentru că în acest caz solicitarea nu ar aduce costuri relevante ofertanților având în vedere că produsele respective există deja pe piață și în portofoliul lor. În plus, pregătirea sesiunii demonstrative nu ar fi de natură să consume resurse importante de timp care să facă necesară prelungirea în mod relevant peste termenele minime a perioadei de depunere a ofertelor. Cerința reclamată se regăsește astfel consemnată la nivelul caietului de sarcini: 4.2.6 Alte cerinţe 4.2.7.1 "Inception Report" si "Analiza-Proiectare" Având in vedere complexitatea proiectului, multitudinea de integrări si cerinţe, ofertantul va trebui sa realizeze la început "Inception Report" si "Analiza-Proiectare" si sa prezinte rezultatele pentru realizarea celei mai bune soluţii si a unei oferte competitive si bine fundamentata, inclusiv tipurile de training necesare. Pagina 56 din 95

Totodată, se va tine cont ca se doreşte funcţionarea paralela, a ambelor sisteme, si cel vechi si cel nou, nu se accepta oprirea vechiului sistem pentru punerea in funcţiune a celui nou. Si acest aspect va fi tratat in "Inception Report" si "Analiza-Proiectare" oferindu-se o soluţie ce va fi acceptata de beneficiar. Se va tine cont de faptul ca se doreşte aplicarea unei politici "park & ride". In cadrul acestor rapoarte, se va descrie/documenta modalitatea de integrare intre sisteme precum si cu sistemele externe solicitate. Toate funcţionalităţile din acest caiet de sarcini se vor demonstra de către ofertanţi la o proba practica, care va face parte din etapa evaluării tehnice a ofertelor, la invitaţia autorităţii contractante. Totodată, având în vedere faptul că se doreşte un standard deschis de interconectare a tuturor sistemelor ITS din platforma de mobilitate, pentru toate echipamentele montate de către ofertant (care respectă standardele deschise susţinute de către ItxPT) se va oferi toată documentaţia de instalare / mentenanţă / interconectare / integrare cu sistemele de e- Ticketing care sunt deja montate pe vehiculele in curs de achiziţie si se va oferi asistenţă pentru integrarea lor în sistemul principal de e-Ticketing, fără costuri suplimentare. Sunt judicioase argumentele aduse de achizitoare în favoarea impunerii cerinței probei practice, aceasta reprezentând o modalitate prin care autoritatea contractantă doreşte să se asigure că sistemul va fi funcţional şi că acesta corespunde solicitărilor şi necesităţilor sale, respectiv permite evaluarea capacităţii reale de implementare a soluţiei ofertate. În mod similar este relevant și argumentul achizitoarei în favoarea păstrării probe practice pentru a reduce riscul atribuirii unui contract neimplementabil, contribuind la protejarea fondurilor publice. Cu alte cuvinte, prin proba practică solicitată achizitoarea elimina pagubele materiale care pot afecta ulterior autoritatea contractantă, fiind o modalitate prin care să verifice daca produsele există, au configuraţiile prezentate, funcţionalităţile solicitate şi îndeplinesc cerinţele caietului de sarcini. Din economia celor anterior redate, Consiliul reține faptul că autoritatea contractantă doreşte susţinerea unei probe practice pentru a se demonstra conformitatea ofertei cu cerinţele caietului de sarcini, aceasta fiind o cerinţă privind propunerea tehnică, şi nu vizează demonstrarea capacităţii tehnice şi/profesionale a ofertanţilor, ci funcţionalitatea tehnică/capacitatea reală de implementare a soluţiei ofertate. Consiliul are în vedere și considerentele reținute de Curtea de Apel București în Decizia nr. 829/05.12.2024, pronunțată în dosarul nr. 6426/2/2024, prin care instanța a modificat în parte Decizia nr. 2741/2024în sensul că a respins critica privind eliminarea cerinței vizând proba practică: Referitor la plângerea formulată de către Autoritatea contractantă, Curtea reţine că, la Capitolul 3 - Descrierea produselor solicitate, din Caietul de sarcini se prevăd următoarele: „În timpul evaluării ofertelor tehnice Autoritatea contractantă va solicita ofertanților, realizarea unei probe practice la sediul și în prezența Autorității contractante. Modalitatea de dovedire a îndeplinirii cerințelor impuse prin caietul de sarcini, la proba practică, cade în sarcina exclusivă a ofertantului. În vederea susținerii practice și verificării conformități echipamentelor ofertate sunt solicitate mostre funcționale pentru aparatele de iluminat, pentru componentele sistemului de Pagina 57 din 95

telegestiune și senzorii propuși. Echipamentele înaintate ca mostre vor fi identice cu cele ofertate în cadrul procedurii și utilizate în calculele luminotehnice. În situația în care se vor identifica diferențe, oferta va fi considerată neconformă și respinsă. Aparatele de iluminat și sistemul de control prezentate trebuie să îndeplinească în totalitate cerințele solicitate prin documentația tehnică, inclusiv cerințele de funcționalitate, a căror îndeplinire se va testa prin instalarea a minim 4 aparate de iluminat stradal echipate cu modul de telegestiune, cu senzor de mișcare, cu senzor ##### și controler inteligent cu rol de gateway. În cadrul probei practice se va testa și comunicația între controlerul inteligent cu platforma software și cu controlerele învecinate. Proba practică constă în alimentarea cu energie și verificarea funcționalității întregului sistem punct cu punct în concordanță cu cerințele din propunerea tehnică. În cazul neprezentării la proba practică oferta va fi declarată neconformă”. Analizând aceste prevederi din cuprinsul Caietului de sarcini, Curtea reţine că prin inserarea acestora, Autoritatea contractantă doreşte să verifice funcţionalitatea întregului sistem şi nu a componentelor acestuia. Contrar celor reţinute de către Consiliu prin Decizia contestată, Curtea constată că această cerință din documentația de atribuire, care prevede efectuarea unei probe practice cu privire la soluția tehnică ofertată, nu are caracteristicile unei cerințe de calificare/unui criteriu de selecție, așa cum în mod eronat a reţinut Consiliul. Principalul scop al unui criteriu de selecție este acelea de a demonstra capacitatea ofertantului de a realiza obiectul contractului, ceea ce nu este cazul în speța de față. Potrivit art. 179 lit. l) din Legea nr. 98/2016, „ Operatorul economic face dovada îndeplinirii cerinţelor privind capacitatea tehnică şi profesională prin prezentarea, după caz, a unora sau mai multora dintre următoarele informaţii şi documente: l) eşantioane, descrieri sau fotografii ale produselor care urmează a fi livrate, a căror autenticitate trebuie certificată la solicitarea autorităţii contractante”. Consiliul a reţinut ca fiind aplicabile prevederile art. 179 lit. l) din Legea nr. 98/2016 mai sus redate, care se referă la dovada îndeplinirii cerinţelor privind capacitatea tehnică şi profesională, Curtea apreciază că aceste dispoziţii legale nu sunt aplicabile în speţă. Astfel, Curtea constată că aceste prevederi legale se referă la prezentarea de eşantioane pentru produsele ce urmează a fi livrate, pe când, în prezenta cauză, solicitarea de prezentare de mostre funcţionale vizează verificarea de către Autoritatea contractantă a funcţionalităţii aplicaţiei de telegestiune/întregului sistem şi care nu poate fi dovedită doar prin intermediul documentelor solicitate, punctual, pentru verificarea conformităţii componentelor sistemului ofertat. Or, Curtea apreciază că proba practică solicitată de către autoritatea contractantă nu constituie un criteriu de selecție, prin care se urmăreşte dovedirea capacităţii ofertantului de a realiza obiectul contractului, ci o cerință specifică caietului de sarcini, prin care este dovedită funcționalitatea soluției tehnice ofertate, în ansamblu, ca sistem, situaţie în care nu era necesară menționarea expresă a acestei cerințe în Anunțul de participare, fiind suficientă precizarea sa în cadrul Caietului de sarcini, dispoziţiile art. 30 alin.(6) din HG nr. 395/2016 nefiind incidente. Curtea subliniază că această cerinţă nu este nici disproporţionată. În acest sens, Curtea relevă că, deşi prin Caietul de sarcini, pentru demonstrarea îndeplinirii specificaţiilor tehnice solicitate ofertanţilor li s-a cerut să depună fişe tehnice, certificate/declaraţii de conformitate şi certificate de test conform cerinţelor tehnice, aceste cerinţe vizează exclusiv produsele reprezentând aparatele de iluminat, nu şi sistemul de telegestiune. În ceea ce priveşte Sistemul de telegestiune, Curtea remarcă faptul că, potrivit menţiunilor din Anexa 7- Sistem de telegestiune, Autoritatea contractantă a solicitat prezentarea de capturi de ecran, însă, aşa cum în mod corect a susţinut şi autoritatea contractantă, prezentarea capturilor de ecran poate fi în măsură să probeze, cel mult, existenţa softului nu însă şi funcţionalitatea acestuia. Aşadar, obligaţia ofertanţilor de a depune certificate de conformitate/certificate de test, pentru aparatele de iluminat şi capturi de ecran, pentru sistemul de telegestiune, nu poate demonstra şi funcţionalitatea sistemului de telegestiune şi, cu atât mai puţin, prezentarea acestor documente nu poate fi în măsură să certifice funcţionalitatea întregului sistem ofertat compus atât din aparate de iluminat, cât şi din sistemul de telegestiune. Pagina 58 din 95

Aşadar, Curtea apreciază că depunerea documentelor anterior menţionate nu este de natură a constitui o alternativă la proba practică solicitată de autoritatea contractantă sau de a înlocui această probă practică. Referitor la practica instanţelor de judecată, invocată de către intimata ######## SRL, Curtea subliniază faptul că trimiterile la respectiva practica judiciară sunt relative la pricinile soluţionate anterior, nu constituie izvor de drept şi nici nu pot obliga la emiterea unei soluţii într-un anumit sens, deoarece precedentul judiciar nu constituie izvor de drept în sistemul românesc. Pentru toate aceste considerente, în temeiul art. 34 din Legea nr. 101/2016, Curtea va respinge, ca nefondată, plângerea formulată de către petenta ######## SRL şi va admite plângerea formulată de către petenta ######## MUNICIPALĂ ILUMINAT ###### BUCUREŞTI şi va desfiinţa în parte Decizia CNSC, în ceea ce priveşte soluţia prin care Consiliul a admis critica contestatoarei, în sensul eliminării cerinței privind proba practică, întrucât, contrar celor reţinute de către Consiliu, Curtea apreciază că această cerinţă nu este nici restrictivă şi nici disproporţionată, prin raportare la obiectul complex al procedurii de atribuire’. Din economia celor anterior redate, Curtea a stabilit că solicitarea unei probe practice nu este o cerință de calificare. Pentru a decide în acest fel, Curtea a reținut că aceasta este o cerință specifică caietului de sarcini, prin care este dovedită funcționalitatea soluției tehnice ofertate, în ansamblu, ca sistem, situaţie în care nu era necesară menționarea expresă a acestei cerințe în anunțul de participare. Consiliul are în vedere că .. SA solicită modificarea documentației de atribuire prin eliminarea cerinței de susținere a unei probe practice, pe motiv că solicitarea unei sesiuni demonstrative pentru aplicaţii de tip .. personalizat sau la comandă (chiar şi pentru părţi din acestea) echivalează cu solicitarea către ofertanţi de a executa total sau parţial viitorul contract de manieră anticipată la nivelul ofertei, o astfel de situaţie fiind excesivă. Consiliul va respinge solicitarea contestatoarei, deoarece rolul probei practice, așa cum s-a arătat, este acela de dovedire a conformității propunerii tehnice. Ori în lipsa verificării conformității, nu se poate stabili oferta câștigătoare. În ceea ce privește caracterul restrictiv al probei practice care impune eliminarea sa de plano, susținut de contestatoare, Consiliul are în vedere că această probă este îndeobște folosită într-un astfel de contract, iar un operator ce furnizează astfel de sisteme, poate, în mod facil, asigura verificarea componentelor în concordanță cu cele solicitate în documentație, dacă aceste informații există. Contestatoarea menționează că pregătirea

unei

sesiuni demonstrative este de natură a aduce costuri semnificative suplimentare ofertanţilor, acestea crescând cu cât cerinţele pentru sesiunea demonstrativă vizează aplicaţii software care nu sunt disponibile deja pe piaţă sau funcţionalităţi care nu există deja la aplicaţii disponibile pe piaţă (aplicaţia respectivă nu este de tip .. - Commercial Of The Shelf, cum este cazul celor mai multe componente din Sistemul de e-ticketing care face obiectul prezentei achiziţii), iar aceste costuri nu pot fi recuperate decât de ofertantul câştigător. Pagina 59 din 95

Consiliul nu neagă faptul că proba practică implică resurse sporite din partea ofertanţilor, respectiv deplasarea la sediul autorităţii pentru proba practică, dar în cadrul procedurilor de atribuire primează interesul public. Consiliul determină că această cerinţă nu este nici disproporţionată. Contestatoarea susține faptul că atât timp cât există metode alternative de verificare a capacităţii tehnice a unui ofertant (criterii de calificare referitoare la experienţa similară prin care se pot solicita referinţe, recomandări, documentaţii şi print-sreen-uri, URL- uri etc.) şi de evaluare a capacităţii/abordării tehnice (cerinţe pentru propunerea tehnică constând în asigurarea unui anumit nivel de pregătire şi experienţă profesională experţilor implicaţi sau în impunerea unei anumite abordări tehnice, factori de evaluare care să puncteze suplimentar experţii mai bine pregătiţi sau abordările tehnice de înaltă calitate), o asemenea cerinţă suplimentară poate avea ca efect încălcarea prevederilor legale legate de proporţionalitate. Contrar celor susținute de contestatoare, Consiliul reține că proba practică este o cerință specifică caietului de sarcini, prin care este dovedită funcționalitatea soluției tehnice ofertate, în ansamblu, ca sistem. Aşadar, Consiliul apreciază că metodele alternative de verificare a capacităţii tehnice a unui ofertant criterii de calificare referitoare la experienţa similară prin care se pot solicita referinţe, recomandări, documentaţii şi print-sreen-uri, URL-uri etc.) şi de evaluare a capacităţii/abordării tehnice (cerinţe pentru propunerea tehnică constând în asigurarea unui anumit nivel de pregătire şi experienţă profesională experţilor implicaţi sau în impunerea unei anumite abordări tehnice, factori de evaluare care să puncteze suplimentar experţii mai bine pregătiţi sau abordările tehnice de înaltă calitate) invocate de contestatoare nu sunt de natură a constitui o alternativă la proba practică solicitată de autoritatea contractantă sau de a înlocui această probă practică. Consiliul reține că aceasta este o cerință specifică caietului de sarcini, prin care este dovedită funcționalitatea soluției tehnice ofertate, în ansamblu, ca sistem. Nu se cere integrare reală, ci simularea funcţionalităţilor cheie. În caietul de sarcini nu se solicită ofertanţilor să aibă acces la infrastructura existentă a autoritatii contractante sau să producă un sistem complet înainte de atribuire. Se cere o demonstraţie rezonabilă a arhitecturii şi capabilităţilor propuse, bazată pe know-how-ul şi soluţiile existente în portofoliul ofertantului. În sprijinul legalității și proporționalității acestei cerințe, există o vastă jurisprudență a Consiliului, cu titlu de exemplu fiind: Decizia nr. . În consecință, Consiliul va respinge solicitarea contestatoarei de eliminare a probei practice. 3) O altă critică formulată de .. SA ( pct. III.2 din contestație) vizează Subsecţiunea 4.2.7.2 prin care se solicită documente justificative pentru experţii non-cheie. Contestatoarea consideră că solicitarea de documente justificative privind experiența relevantă a experţilor non- cheie este excesivă prin raportare la principiul proportionalității. Contestatoarea precizează că în cadrul Subsecţiunii 4.2.7.2 Necesar personal Non Cheie din caietul de sarcini, există cerinţa de a prezenta în Pagina 60 din 95

cadrul ofertei obligatoriu „câte o persoana desemnata din fiecare personal non cheie, care sa indeplineasca rolurile de Senior HW Engineer / Echivalent si Senior SW Engineer / Echivalent". De asemenea, cu privire la aceşti experţi non-cheie, caietul de sarcini prevede necesitatea de a se depune documente justificative care atestă experienţa anterioară a acestora în proiecte relevante. Cerinţa de a depune documente justificative privind experienţa relevantă a experţilor non-cheie este apreciată de contestatoare ca fiind excesivă excesivă prin raportare la principiul proporţionalităţii şi la prevederile art. 155 alin. (6) din Legea nr. 98/2016, coroborat cu art. 20 alin. (10) din HG nr. 395/2016, precum şi la Instrucţiunea ANAP nr. 1/2017, potrivit căreia solicitarea de documente justificative în acest context reprezintă una dintre cele mai frecvente neconformităţi identificate în cadrul documentaţiilor de atribuire de către ANAP, cu ocazia controlului ex-ante, efectuat în conformitate cu Ordonanţa de urgenţă nr. 98/2017. Concluzia la care ajunge contestatoarea este aceea că se impune eliminarea cerinţei de a prezenta documentele justificative care dovedesc experienţa experţilor non-cheie în cadrul propunerii tehnice şi alinierea cu îndrumarea ANAP. Se vor reține și precizările autorității contractante în replică la cele reclamate, respectiv faptul că în contextul unui contract care implică dezvoltare IT, integrare de sisteme şi configurare complexă de echipamente, rolul experţilor tehnici non-cheie este esenţial. Prin urmare solicitarea unor documente justificative care să ateste experiența asimilată in cadrul unor proiecte similare, are ca scop verificarea realităţii şi calificării personalului tehnic propus. Concluzia achizitoarei este aceea că solicitarea documentelor justificative privind experienta experţilor non-cheie este proporţională, adecvată şi necesară pentru buna implementare a contractului şi continuitatea serviciilor publice. Cerințe privind personalul non cheie se regăsesc la nivelul caietului de sarcini, fiind astfel formulate: 4.2.7.2 Necesar personal Non Cheie Avand in vedere complexitatea sistemului, pe langa Personalul Cheie solicitat in Factorii de evaluare ofertantul va avea in componenta echipei de proiect, obligatoriu cate o persoana desemnata din fiecare personal non cheie, care sa indeplineasca rolurile de Senior HW Engineer / Echivalent si Senior SW Engineer / Echivalent. Ei nu vor fi punctati ca si factori de evaluare în cadrul procedurii de atribuire, dar trebuie totuşi menţionaţi în echipa de proiect şi în planul de implementare sau echivalent. A) Senior HW Engineer / Echivalent Descriere: Se va evalua experienţa profesională relevantă a expertului propus pentru poziţia de Senior HW Engineer sau cu rol echivalent (ex. Hardware Systems Specialist, Embedded Systems Engineer, Transport Infrastructure Engineer), dobândită în cadrul unor proiecte similare. Prin proiecte similare se înţeleg acele proiecte care au inclus componente de: - Proiectare, furnizare, instalare sau integrare de echipamente hardware pentru sisteme de ticketing (cititoare de carduri/contactless, validatoare, echipamente de bord etc.); Pagina 61 din 95

- Implementarea de infrastructură inteligentă la bordul vehiculelor de transport public (ex. comunicaţii vehicul-infrastructură, senzori, echipamente de reţea, protocoale de comunicaţie industrială). Documente justificative necesare: - CV-ul expertului; - Declaraţie de disponibilitate, semnată de expertul propus; - Documente care atestă experienţa în proiecte relevante (contracte, certificate de bună execuţie, procese-verbale de recepţie, recomandări sau alte documente oficiale emise de beneficiari). Justificare solicitare: Prezenţa unui specialist hardware cu experienţă în sisteme de ticketing şi infrastructură inteligentă este esenţială pentru asigurarea compatibilităţii echipamentelor, fiabilităţii comunicaţiilor şi integrării eficiente în sistemul general. Acest rol contribuie la selecţia şi configurarea optimă a componentelor hardware, precum şi la rezolvarea problemelor tehnice apărute în faza de implementare. B) Senior SW Engineer / Echivalent Descriere: Se va evalua experienţa profesională relevantă a expertului propus pentru poziţia de Senior SW Engineer sau cu rol echivalent (ex. Software Developer, Backend Engineer, Data Integration Specialist), dobândită în cadrul unor proiecte similare. Prin proiecte similare se înţeleg acele proiecte care au inclus: - Dezvoltarea sau integrarea de soluţii software pentru sisteme de ticketing, platforme de date urbane (ex. FIWARE), portaluri unice pentru utilizatori, dashboarduri de analiză (ex. Tableau, Power BI); - Interoperabilitate cu sisteme de tip ITS (ex. Swarco) sau alte platforme publice/bancare. Documente justificative necesare: - CV-ul expertului; - Declaraţie de disponibilitate, semnată de expertul propus; - Documente care atestă experienţa în proiecte relevante (contracte, certificate de bună execuţie, procese-verbale de recepţie, recomandări sau alte documente oficiale emise de beneficiari). Justificare solicitare: Senior SW Engineer contribuie la dezvoltarea, personalizarea şi integrarea componentelor software ale sistemului. Expertiza sa este necesară pentru a asigura interoperabilitatea între module, respectarea cerinţelor funcţionale şi integrarea cu platforme externe. Acest rol este esenţial pentru livrarea unei soluţii scalabile, moderne şi conforme cu standardele actuale în domeniul transportului public inteligent. Raționamentul conturat de contestatoare în favoarea eliminării solicitării cerinţei de a prezenta documentele justificative care dovedesc experienţa experţilor non-cheie în cadrul propunerii tehnice şi alinierea cu îndrumarea ANAP nu este judicios și nu va fi reținut de Consiliu în soluționare din considerentele mai jos expuse. Pornind de la premizele care au stat la baza elaborării documentației de atribuire în vederea atribuirii contractului de furnizare (care cuprinde și prestarea de servicii aferente), importanța acestuia, durata contractuală și rezultate așteptate de la derularea proiectului, asigurarea posibilității depunerii unor oferte conforme, precum și specificacitatea acestuia (caietul de sarcini, descrie un sistem informatic complex - o platformă digitală integrată de mobilitate urbană, care include o serie de componente şi funcţionalităţi), Consiliul reține atenția sporită pe care autoritatea contractantă a acordat-o necesarului de resurse de personal. Pagina 62 din 95

În raport de cele mai sus redate, Consiliul determină că prioritar este interesul public unde așteptările și nevoile sunt foarte mari, astfel că se încheie contractul pentru realizarea unor sarcini ale interesului public (.. urmăreşte să creeze un ecosistem digital unitar, sigur şi interoperabil, în deplină concordanţă cu obiectivele de digitalizare promovate la nivel european). Analizând necesarul de personal non-cheie solicitat Consiliul reține că rolul experţilor non-cheie în acest proiect nu este de neglijat, din contră într-un sistem de e-ticketing integrat cu multiple platforme (ERP, Omnia, FIWARE, Webcon etc.), calitatea livrării depinde în mod direct şi de aportul acestor experţi. În stabilirea acestei finalități, Consiliul apreciază ca fiind justă rațiunea justificării prezenței experţilor non-cheie solicitați, respectiv: - Prezenţa unui specialist hardware cu experienţă în sisteme de ticketing şi infrastructură inteligentă este esenţială pentru asigurarea compatibilităţii echipamentelor, fiabilităţii comunicaţiilor şi integrării eficiente în sistemul general. Acest rol contribuie la selecţia şi configurarea optimă a componentelor hardware, precum şi la rezolvarea problemelor tehnice apărute în faza de implementare - Senior SW Engineer contribuie la dezvoltarea, personalizarea şi integrarea componentelor software ale sistemului. Expertiza sa este necesară pentru a asigura interoperabilitatea între module, respectarea cerinţelor funcţionale şi integrarea cu platforme externe. Acest rol este esenţial pentru livrarea unei soluţii scalabile, moderne şi conforme cu standardele actuale în domeniul transportului public inteligent. Din economia celor anterior redate Consiliul determină importanța personalului non cheie în atingerea rezultatelor așteptate de la derularea proiectului în cauză. Față de importanța rolului experților non-cheie solicitați, Consiliul apreciază că solicitarea unor documente justificative care sa ateste experiența asimilată în cadrul unor proiecte similare, este esenţială pentru a evalua în mod adecvat capacitatea ofertantului de a realiza proiectul propus, oferind asigurări privind stabilitatea, resursele şi competenţele necesare pentru succesul acestuia. Respectiva cerință are ca scop verificarea realităţii şi calificării personalului tehnic propus, motiv pentru care cerinţă nu incalca principiul proporţionalitatii, având în vedere complexitatea şi riscurile asociate implementării proiectului în cauză a cărui complexitate și specificitate a fost reținută. Deopotrivă de valide sunt și apărările aduse de autoritatea contractantă: - Instrucţiunile ANAP sunt orientative şi nu interzic solicitarea de documente pentru experţii non-cheie. În acest proiect, autoritatea contractanta a considerat justificată cerinţa, având în vedere riscurile de implementare defectuoasă în lipsa unei echipe documentate; - Răspunsul autoritatii contractante este justificat prin prisma specificului proiectului. Experţii non- cheie contribuie direct la succesul implementării, iar documentarea lor încă din ofertare asigură transparenţă şi comparabilitate între ofertanţi; - Rolul unui expert nu este definit doar prin titulatura de 'cheie' sau 'non-cheie', ci prin impactul asupra livrării. În acest proiect, experţii non-cheie au atribuţii critice, iar documentarea lor este necesară pentru validarea ofertei; Pagina 63 din 95

- Cerinţa nu este abuzivă. Ea nu impune sarcini excesive, ci doar dovada competenţei experţilor propuşi. Este rezonabil ca toţi membrii echipei să fie documentaţi, având în vedere complexitatea şi impactul proiectului; - Eliminarea cerinţei ar reduce transparenţa şi ar creşte riscul ca ofertanţii să propună echipe nevalidate. Solicitarea documentelor justificative este o măsură preventivă, care asigură seriozitatea şi fezabilitatea ofertei. Așadar, argumentele avute de achizitoare la baza impunerii cerinței vizează aspecte legate de capacitatea ofertanților de a duce la îndeplinire contractul, oferind asigurări privind stabilitatea, resursele şi competenţele necesare pentru succesul acestuia. Din economia celor redate rezultă că autoritatea contractantă a apreciat că specificul proiectului justifică o abordare mai riguroasă, tocmai pentru a proteja interesul public şi pentru a preveni întârzieri sau implementări defectuoase. Prin solicitarea documentelor justificative privind experienta experţilor non-cheie nu se impun sarcini excesive ofertanţilor, ci doar dovada competenţei efective a experţilor menţionaţi în ofertă, astfel nu se poate reține încălcarea principiului proporționalității. Este rezonabil să se ceară încă din ofertare ca toţi membrii echipei - cheie şi non-cheie - să fie documentaţi, dat fiind că proiectul implică un ecosistem tehnologic complex, extins şi critic pentru serviciile publice de transport. Consiliul achiesează la argumentele achizitoarei, în stabilirea acestei finalități se are în vedere că autoritatea contractantă trebuie să evalueze fiecare procedură de achiziţie publică, în parte, şi să aleagă modalitatea de organizare a procedurii aplicabile şi de întocmire a documentaţiei de atribuire, care să asigure cel mai bine atingerea scopului urmărit prin încheierea contractului şi o utilizare cât mai eficientă a fondurilor publice. Așadar, revine autorităţii contractante rolul de a asigura un echilibru între interesele sale (în condiţiile în care regula este aceea a priorităţii interesului public, în dauna celui privat, al operatorilor economici) și modalitatea de atingere a acestora - ceea ce presupune stabilirea obiectului contractului, a documentaţiei şi a întregii proceduri de atribuire precum şi respectarea legislaţiei în materia achiziţiilor publice. Așa cum au statuat instanțele de judecată este de subliniat faptul că agenții economici sunt cei care trebuie să se adapteze solicitărilor autorităților, și nu invers: Decizia nr. pronunțată de Curtea de Apel București în dosarul nr. .) ”(..) Este de subliniat faptul că agenții economici sunt cei care trebuie să se adapteze solicitărilor autorităților, și nu invers. Dacă este adevărat că legea este restrictivă în ceea ce privește dreptul autorităților de a face atribuiri fără lotizare sau cu o lotizare care să ducă la îngrădirea concurenței (prin includerea unor condiții restrictive care să creeze vocație exclusivă unui anumit ofertant), trebuie observat, totuși, că nicio dispoziție legală sau principiu general nu conduce la ideea că autoritatea contractantă ar trebui să-și întocmească documentația de atribuire după criterii care să pună interesele potențialilor ofertanți înaintea interesului său de atingere a interesului public urmărit (...). Pagina 64 din 95

Așa cum a fost anterior reținut prioritar este interesul public unde așteptările și nevoile sunt foarte mari, astfel că se încheie contractul pentru realizarea unor sarcini ale interesului public. Consiliul are în vedere faptul că prezentul contract de achiziție ce se dorește a fi încheiat este un contract administrativ și nu comercial, contractul de achiziție publică fiind definit la art. 3 alin. (1) lit. l) din Legea nr. 98/2016 (contract de achiziţie publică - contractul cu titlu oneros, asimilat, potrivit legii, actului administrativ, încheiat în scris între unul sau mai mulţi operatori economici şi una ori mai multe autorităţi contractante, care are ca obiect execuţia de lucrări, furnizarea de produse sau prestarea de servicii). În acest context, având în vedere că prin contractul administrativ administrația publică (sau entitățile asimilate) își realizează o parte din sarcinile sale, se consideră că regimul juridic aplicabil acestor contracte este unul exorbitant, de drept public. Consiliul are în vedere că, într-un mod general, scopul contractelor, actelor administrative este de a asigura funcționarea serviciilor publice și de a da astfel satisfacție intereselor generale. Prerogativele de drept public la îndemâna administrației constau in fapt ca administrația încheie contractul pentru realizarea unor sarcini ale interesului public, ceea ce o pune în situație privilegiată. Voința administrației ca parte contractantă este subordonată realizării interesului general. Contractelor administrative, comparativ cu cele de drept privat li se aplica reguli mai tehnice, administrația are limite de acțiune, are o competență legată, fiind ținuta de dispozitiile legale și de satisfacerea interesului general, iar particularul este ținut de clauzele exorbitante derogatoriu propuse și impuse de administrație. Prerogativele de putere publică ale administrației au la bază faptul că administrația încheie contractul în scopul de a satisfice un interes general, ceea ce dă administrației posibilitatea de a impune clauze exorbitante în contract, de a controla modul de executare a contractului și de a dispune rezilierea contractului atunci când interesul public nu mai primește, prin executarea contractului, o satisfacție completă și continuă. Clauzele exorbitante sunt clauze derogatorii de la dreptul comun şi care consacră puteri sporite în favoarea entităţii publice pe considerentul ocrotirii interesului public. Acestea sunt de obicei prevăzute în caietul de sarcini, precum şi în actul normativ care reglementează respectivul contract. Astfel, orice contract cu o entitate publică centrală sau locală cuprinde clauze ce pot fi considerate exorbitante pentru particulari, dată fiind calitatea aparte a beneficiarului și destinația vizând interesul public a contractului, se are în vedere regula după care principiul libertății contractuale este subordonat principiului priorității

interesului public. Astfel, orice contract cu o entitate publică centrală sau locală cuprinde clauze ce pot fi considerate exorbitante pentru particulari, dată Pagina 65 din 95

fiind calitatea aparte a beneficiarului și destinația vizând interesul public a contractului. În consecință, se reține că și contractele de achiziție publică presupun anumite rigori pe care trebuie să le accepte cei care doresc să se implice într-o relație contractuală cu statul sau cu entitățile sale publice. Pornind de la faptul că pentru achizitoare era de interes proba faptului că un efectiv adecvat de personal asigură capacitatea ofertanților de a duce la îndeplinire contractul, dovada competenţei efective a experţilor non-cheie asigură autoritatea contractantă că proiectul va fi realizat la parametrii calitativi solicitaţi oferind asigurări privind stabilitatea, resursele şi competenţele necesare pentru succesul acestuia, tocmai pentru a proteja interesul public şi pentru a preveni întârzieri sau implementări defectuoase. Față de cele anterior reținute solicitările contestatoarei se impun a fi respinse. 4) O altă critică formulată de .. SA ( pct. IV din contestație) vizează faptul că cerinţa stabilită prin caietul de sarcini ca sistemul nou de e- ticketing să ofere integrare cu platformele FIWARE şi SynchroniCity determină restrângerea artificială a concurenţei. Argumentele aduse de autoarea contestației în favoarea criticilor aduse se bazează pe următoarele aspecte: - în primul rând, astfel cum rezultă din prevederile art. 156 alin. (2) din Legea nr. 98/2016, referirea la o tehnologie concretă cu care trebuie să se asigure integrarea este interzisă. (...) Dar chiar şi în această situaţie absolut excepţională, nu este în niciun caz posibilă limitarea la o singură tehnologie concretă (cum sunt platformele FI WARE şi SynchroniCity), fiind obligatoriu să se menţioneze în documentaţia de atribuire posibilitatea furnizării de soluţii echivalente; - în al doilea rând, FIWARE şi SynchroniCity nu au caracter de standard obligatoriu, astfel încât evaluarea propunerilor tehnice prin raportare la compatibilitatea cu o singură categorie de tehnologii nestandardizate generează riscul unui rezultat arbitrar şi neconformitate tehnic; - în al treilea rând, autoritatea contractantă nu a prezentat o justificare clară din care să rezulte că utilizarea exclusivă a celor două tehnologii, fară nicio posibilă soluţie echivalentă, ar genera beneficii directe pentru cetăţeni sau pentru funcţionalitatea sistemului de e-ticketing; - în al patrulea rând, chiar în cadrul Caietului de sarcini, Secţiunea 4.2.5 Standarde şi normative de respectat, este solicitată în mod expres respectarea altor standarde pentru integrare (transfer si schimb de date), respectiv modelul de referinţă european pentru datele din transportul public, formatul de transfer si schimb de date - Transmodel, împreună cu toate modelele acoperite: NeTEx, SIRI, OpRa, OJP, GTFS și GTFS- RT; - în al cincilea rând, din Secţiunea 14 Factori de evaluare din Caietul de Sarcini, pct. 2.1 rezultă că se va acorda punctajul maxim din perspectiva acestui criteriu de evaluare doar dacă propunerea tehnică include integrarea standardelor FIWARE şi SynchroniCity în centrul arhitecturii, favorizând astfel în mod nejustificat ofertanţii deja integraţi în aceste sisteme şi distorsionând concurenţa. Față de cele invocate contestatoarea solicită obligarea autorității contractante să adopte măsuri de remediere pentru a permite furnizarea unor soluţii echivalente cu privire la integrarea sistemului de e-ticketing. Se vor reține și argumentele aduse de autoritatea contractantă în replică la cele reclamate, în favoarea impunerii cerinței de integrare: Pagina 66 din 95

Integrarea cu FIWARE şi SynchroniCity nu urmăreşte restrângerea concurenţei, ci: • asigurarea interoperabilităţii între sistemul nou de e-ticketing şi soluţiile digitale deja utilizate de autoritatea contractantă (ex: proiectul de video-analytics dezvoltat în FIWARE); • evitarea dependenţei faţă de un singur furnizor („vendor lock-in"), prin utilizarea unor standarde europene deschise; • crearea unui ecosistem urban digital unitar, bazat pe reutilizarea componentelor open-source şi pe integrarea cu alte servicii publice (trafic, parcări, mobilitate, GIS etc.). Cerința reclamată se regăsește formulată în cadrul documentației de atribuire astfel: - la nivelul fișei de date, pct. II. 1.4) din fişa de date II.1.4 Descrierea succinta a contractului sau a achizitiei/achizitiilor Contractul ce urmează a fi atribuit presupune furnizarea unui sistem nou de e-ticketing, care sa respecte cerintele Caietului de sarcini, si anume: (...) -

Sa

ofere

integrare

cu

platforma

europeana

SynchroniCity (https://www.synchronicityiot.eu/knowledge/technical-framework/) - Sa ofere integrare cu platforma FIWARE (https://www.fiware.org/about-us/) FIWARE este o platformă open-source care facilitează dezvoltarea de aplicații inteligente pentru diverse domenii, inclusiv orașele inteligente. - la nivelul caietului de sarcini Secţiunea 2.1 Obiectivul Achiziţiei: - Sa

ofere

integrare

cu

platforma

europeana

SynchroniCity (https://www.synchronicity- iot.eu/knowledge/technical-framework/) - Sa ofere integrare cu platforma FIWARE (https://www.fiware.org/about-us/) FIWARE este o platformă open-source care facilitează dezvoltarea de aplicaţii inteligente pentru diverse domenii, inclusiv oraşele inteligente. Aceasta oferă un set de componente reutilizabile, cunoscute sub numele de Generic Enablers (GEs), care permit colectarea, gestionarea şi analiza datelor în timp real. - potrivit Secţiunii 7.4 Integrarea cu sisteme externe din Caietul de sarcini 7.4 Integrarea cu sisteme externe 7.4.1 Fiware Se doreşte integrarea cu platforma open source FIWARE Mai multe detalii la adresa: https://www.fiware.org/about-us/ 7.4.2 SynchroniCity Se doreşte integrarea cu platforma SunchroniCity Mai multe detalii aici: https://www.synchronicity-iot.eu/knowledge/technical- framework/ Informații detaliate referitoare la platforma open source FIWARE sed regăsesc în caietul de sarcini, respectiv: PLATFORMA FIWARE (...) Sistemul de e-ticketing licitat prin acest Caiet de Sarcini, este un element cheie in Solutia "Cross Platform" mobiliTM pe care Beneficiarul doreşte sa o implementeze Totuşi, pentru ca integrarea Interplatforme sa funcţioneze, este necesar ca Sistemul de e-ticketing sa aibă la baza o serie de informaţii si reguli standardizate de schimb de informaţii in format securizat. Pentru realizarea acestui deziderat, se vor folosi tehnologii sustinute de Uniunea Europeana prin strategia "Digital Agenda 2020" si anume Fiware FIWARE - a European success story | Shaping Europe's digital future Platforma mobiliTM, oferă o gamă variată de funcţionalităţi pentru cetăţeni, companii şi oraşe. În diagrama de mai jos este prezentată arhitectura modulară a platformei mobiliTM, care va livra in cadrul acestui caiet de sarcini prin sistemul de e-Ticketing, următoarele Pagina 67 din 95

componente. Ele sunt toate integrate într-o platformă open source, FIWARE, şi au două zone de aplicabilitate: • O zonă de front-office, publică, care se interfaţează cu cetăţeanul, companiile şi oraşul; • O zonă de back-office, care este internă Primăriei şi entităţilor partenere în livrarea serviciului de mobilitate prin transport în comun: STPT, SMTT, şi Poliţia locală pe partea de ordine publică. FIWARE este o platformă open source concepută pentru a facilita dezvoltarea aplicaţiilor inteligente în diverse sectoare, inclusiv mobilitatea urbană. FIWARE oferă un set de API-uri standardizate şi componente modulare, cunoscute sub numele de Generic Enablers (GEs), care simplifică gestionarea informaţiilor contextuale şi integrarea diverselor servicii şi soluţii. Avantajele folosirii sistemului FIWARE: • Open Source: FIWARE este o platformă open source, ceea ce înseamnă că oricine poate contribui la dezvoltarea şi utilizarea acesteia. • APIs Standardizate: Oferă API-uri publice şi fără redevenţe, care facilitează dezvoltarea aplicaţiilor inteligente. • Comunitate Deschisă: FIWARE este susţinută de o comunitate globală de dezvoltatori şi organizaţii care contribuie la ecosistemul FIWARE. • Gestionarea Informaţiilor Contextuale: Permite gestionarea şi actualizarea informaţiilor contextuale în timp real, esenţială pentru aplicaţiile inteligente. 4.2.1 Integrarea funcţionalităţilor sistemului de e-Ticketing in soluţiile cloud scalabile FIWARE va fi utilizat ca backbone pentru arhitectura sistemului livrat pentru a integra diverse componente ale unei platforme de mobilitate prin următoarele modalităţi. Următoarele funcţionalităţi vor fi furnizate in acest proiect integrate toate in FIWARE si cu API-uri la nivel de fiecare componenta; 1. Componenta de taxare/procesare de plăţi (e-TAX): o Front-office: Integrarea nativa instrumentelor de eticketing cu sistemul de single sign- on (SSO) al portalului unic cont.primariatm.ro, permiţând utilizatorilor să acceseze toate funcţionalităţile dintr-un singur cont. Furnizarea a diverselor opţiuni de plata pentru acces la transportul in comun sau programele de fidelizare; o Back-office: Utilizarea FIWARE pentru a conecta componenta de planuri de tarifare flexibile şi a genera rapoarte de utilizare a mijloacelor de transport în comun. 2. Componenta de e-Monitorizare si Informare calatori (e-MIC) - o Planificarea traseelor: 1. Front-office: Oferirea unei funcţionalităţi de urmărire si planificare a traseelor multimodale pentru cetăţeni (similar cu functionalitatea .. care este folosita momentan de STPT), integrată cu diverse moduri de transport (tramvaie, troleibuze, autobuze, vapporetto) si posibilitatea extinderii lui pe viitor la alte forme de transport intr-o abordare multi-modala; 2. Back-office: Gestionarea resurselor umane şi a vehiculelor pentru a asigura echilibrarea rutelor şi calitatea serviciilor furnizate. o Gestionarea conţinutului audio-video: 1. Back-office: Controlul în timp real al conţinutului afişat pe ecranele din staţii şi vehicule, utilizând FIWARE pentru a asigura actualizări rapide şi precise. o Video analytics: 1. Back-office: integrarea cu sistemul de capturarea şi analiza streamurilor video din staţii şi vehicule pentru a estima fluxurile de pasageri în timp real. Aceasta functionalitate are infrastructura deja realizata in centrul de monitorizare trafic in cooperare cu Politia Locala. Metadatele cu evenimentele din aceasta platforma vor si colectate si consolidate intr-un dashboard comun cu aplicatia de e-monitorizare e-MIC; o Sistemul de antifraudare: 1. Back-office: Acest sistem se va baza pe tehnologia IRMA MATRIX ( https://www.iris-sensing.com/products/irma-matrix/ ) care este un senzor 3D avansat dezvoltat de iris intelligent sensing pentru numărarea automată a pasagerilor în mijloacele de transport public. Tehnologia utilizează tehnologia time-of-flight, permiţând detectarea precisă a numărului de persoane şi a obiectelor, precum scaune cu rotile, cărucioare sau biciclete. Senzorul funcţionează eficient indiferent de condiţiile de iluminare şi poate transmite în timp real date despre numărul de pasageri, facilitând îmbunătăţirea serviciilor de transport public. Pagina 68 din 95

2. Front-office: posibilitatea de a afişa in vehicul in timp real a numărului de pasageri on-board si numărul de pasageri nevalidaţi încă; o Sistemul de control al ecranelor si notificare/publicitate: 1. Back-office: Se vor putea gestiona de la distanta in timp real toate ecranele din statiile de transport in comun si cele de pe vehicule; 2. Front-office: se vor putea rula pe aceste ecrane continut si notificari audio- video cu caracter public si de reclame; o Analiza si controlul traficului: 1. Back-office: Analiza şi controlul traficului prin monitorizarea şi controlul traficului (integrare cu ultimul upgrade la platforma Omnia/Swarco). Acest upgrade se va face printr-o achiziţie separata. 2. Back/Front-office: Integrarea cu aplicaţia de mobilitate Waze pentru a insera automat prin API informatii despre trafic in timp real. Google oferă programul Waze for Cities (fost Waze Connected Citizens Program - CCP), prin care administraţiile locale pot accesa şi trimite date despre trafic şi infrastructură. Datele vor fi accesate prin feed-uri JSON/XML şi integrate în sistemele de management al traficului, astfel incat ele sa poata fi folosire pentru analiza traficului şi luarea deciziilor privind mobilitatea urbană. 3. Interoperabilitate: o FIWARE facilitează interoperabilitatea între diverse sisteme şi platforme, permiţând integrarea uşoară a noilor servicii şi tehnologii în platforma de mobilitate. 4. Raportare: o Sa se creeze o arhitectura de dashboard integrata bazata pe sisteme de business intelligence (BI) de tip Tableau sau Power BI care sa aibe incluse in oferta licentierea pe perioada acestui proiect (inclusive perioada de garantie) pentru cel putin 50 de uilizatori precum si toata infrastructura de client/server necesara; 5. Scalabilitate: o Sa ofere posibilitatea unei scalabilitati dinamice a solutiei software prin utilizarea orchestratoare de tip Kubernetes sau echivalent şi containerizare de tip Docker sau echivalent; o Sa ofere posibilitatea de instalare atat în Cloud cât şi pe computere fizice/virtuale, daca se doreste. Din economia argumentelor aduse de achizitoare în cadrul punctului de vedere, Consiliul reține că rațiunea care a stat la baza stabilirii cerinței reclamate izvorăște din asigurarea interoperabilităţii între sistemul nou de e-ticketing şi soluţiile digitale deja utilizate de autoritatea contractantă (ex: proiectul de video-analytics dezvoltat în FIWARE) și crearea unui ecosistem urban digital unitar, bazat pe reutilizarea componentelor open-source şi pe integrarea cu alte servicii publice (trafic, parcări, mobilitate, GIS etc.). Din lecturarea informațiilor precizate în cadrul caietului de sarcini, este important de punctat faptul că FIWARE şi SynchroniCity sunt iniţiative europene dezvoltate cu finanţare publică, având drept scop promovarea interoperabilităţii şi reutilizării soluţiilor digitale în mediul urban. Ambele platforme sunt liber accesibile, deschise şi non-restrictive din punct de vedere comercial, fără costuri de licenţiere şi cu suport comunitar activ. Referior la susținerile contestatoarei vizavi de lipsa formulării „sau echivalent" aspect care limitează soluţiile similare, autoritatea contracatntă a explicat faptul că Cerinţa vizează mecanismele funcţionale de interoperabilitate, nu o implementare rigidă. În mod implicit, orice ofertant poate demonstra compatibilitatea prin soluţii echivalente, autoritatea contractantă urmand sa aplice principiul echivalenţei consacrat de art. 156 alin. (2) din Legea 98/2016 privind Pagina 69 din 95

achizitiile publice. Precizam ca acest principiu a fost mentionat atat in Anexa 2 la Caietului de sarcini (pag.90), intitulata Formular de Propunere tehnica, cat si la nivelul Fisei de date, sectiunea IV.4.1 Modul de prezentare al propunerii tehnice. Din lecturarea referințelor indicate, Consiliul determină temeincia susținerilor achizitoarei, fiind precizate următoarele: - fișa de date: 5. Cerintele tehnice definite la nivelul anuntului de participare, caietului de sarcini sau altor documente complementare, prin trimiterea standardelor, la un anumit producator, la marci, brevete, tipuri, la o origine sau la o productie/metoda specifica de fabricatie/prestare/executie, vor fi intelese ca fiind insotite de mentiunea ”sau echivalent”. - ANEXA 2- Formular de Propunere Tehnică: Ofertanţii vor completa si transmite prezenta "propunere tehnică" Propunerea tehnica se va întocmi într-o maniera organizata, astfel încât procesul de evaluare a ofertelor sa permită identificarea facila a corespondentei informaţiilor cuprinse in oferta cu specificaţiile tehnice din Caietul de Sarcini. Specificaţiile aferente Caietului de Sarcini reprezintă cerinţe minimale referitoare la nivelul calitativ, si de performanta, scop in care soluţiile ofertate in cadrul Propunerii Tehnice pot face referire la atingerea unor niveluri superioare. Orice referire din caietul de sarcini cu privire la denumire firma, marca, sistem de fabricaţie, etc, va fi însoţita de sintagma „sau echivalent”. Ori câtă vreme scopul cerinţei este să asigură interoperabilitate şi continuitate cu infrastructura digitală deja implementată, iar așa cum a susținut și autoritatea contractantă (conform art. 156 din Legea nr. 98/2016, autoritatea contractantă aplică principiul echivalenţei, iar menţiunea expresă „sau echivalent" este implicit aplicabilă în cazul specificării unor standarde tehnice deschise) rezultă că orice ofertant poate propune soluţii echivalente, cu condiţia să asigure aceleaşi mecanisme de interoperabilitate. Așadar, rezultă faptul că cerința de integrare nu limitează accesul operatorilor economici. Față de susținerile contestatoarei, autoritatea formulează apărări pe care Consiliul le apreciază credibile și concludente: Cerinţa autoritatii contractante nu impune tehnologii comerciale, ci standarde deschise precum FIWARE şi SynchroniCity. Acestea sunt cadre tehnice promovate de Comisia Europeană pentru a evita dependenţa de un singur furnizor şi pentru a permite interoperabilitatea între soluţii diverse. Ele pot fi implementate liber, fără licenţe, de orice operator comercial. Autoritatea contractanta nu exclude echivalenţa, ci solicită alinierea la un set de specificaţii deschise. Orice operator poate adapta soluţia sa pentru a respecta aceste standarde, exact cum se întâmplă cu NeTEx, SIRI sau GTFS. Cerinţa nu favorizează un furnizor, ci promovează interoperabilitatea reală. A construi arhitectura în jurul FIWARE/SynchroniCity nu înseamnă impunerea unei soluţii comerciale, ci alinierea la un cadru tehnic deschis, recunoscut la nivel european. Aceste standarde permit integrarea cu alte servicii urbane şi evită fragmentarea tehnologică. FIWARE defineşte un nucleu arhitectural deschis, bazat pe API-uri NGSI-LD şi context brokers. Acest model este deja utilizat în sute de oraşe europene şi permite interoperabilitatea între componente diverse. Nu este o restricţie, ci o alegere strategică pentru coerenţă tehnologică si cu proiectele viitoare. Adaptarea la FIWARE/SynchroniCity nu presupune rescriere completă, ci compatibilizare cu modele de date şi interfeţe deschise. Operatorii pot reutiliza componente existente şi le pot calibra pentru a respecta aceste standarde, fără a fi obligaţi să adopte o platformă unică. Autoritatea

contractanta

nu

limitează

interoperabilitatea

la FIWARE/SynchroniCity, care sunt standarde de smartcity. Caietul de sarcini include explicit şi standarde precum NeTEx, SIRI, GTFS, OpRa, OJP, care sunt standarde de mobilitate Cerinţa este completă şi acoperă toate zonele funcţionale relevante pentru transport public şi smart city. Pagina 70 din 95

Autoritatea contractanta recunoaşte şi include standardele CEN (NeTEx, SIRI, OpRa, OJP) şi GTFS/GTFS-RT. Acestea sunt complementare FIWARE/SynchroniCity şi împreună asigură interoperabilitatea atât în domeniul transportului, cât şi în alte verticale urbane. Referinţa la proiectul anterior nu este disproporţionată, ci justificativă. Ea arată că autoritatea contractanta are deja infrastructură compatibilă cu FIWARE, iar cerinţa actuală urmăreşte integrarea şi extinderea acesteia intr-un mod interoperabil, nu impunerea unei soluţii comerciale. Autoritatea contractanta nu impune exclusiv FIWARE. Cerinţa este ca soluţia să fie compatibilă cu acest cadru, nu să fie construită doar pe el. Se acceptă şi alte standarde, iar interoperabilitatea este obiectivul principal. Autoritatea contractanta acceptă soluţii echivalente, cu condiţia ca acestea să respecte specificaţiile de interoperabilitate. FIWARE/SynchroniCity sunt deschise şi neutre, iar orice operator le poate implementa fără restricţii. Cerinţa nu limitează concurenţa. Deopotrivă de valide sunt și apărările achizitoarei în favoarea impunerii cerinței de integrare respectiv: Contestatoarea confundă în mod eronat standarde tehnice cu soluţii comerciale. • FIWARE şi SynchroniCity nu sunt produse, ci specificaţii şi cadre tehnice deschise, dezvoltate prin iniţiative europene (Comisia Europeană, Horizon 2020, OASC, Living-in.EU) care acopera necesitatea de integrare a solutiilor de smartcity. Ele au fost gandite si propuse pentru a putea fi folosite liber, gratuit şi de oricine. Alegerea lor nu presupune licenţe comerciale, nu limitează accesul şi nu favorizează niciun operator economic. • Cerinţa ca arhitectura să fie construită „în jurul" acestor standarde nu înseamnă impunerea unei soluţii proprietare, ci alinierea la un set de specificatii, cum ar fi interfete, API-uri, modele de date şi mecanisme de interoperabilitate care sunt deja recunoscute la nivel european şi implementate în sute de oraşe. Orice operator poate să îşi calibreze soluţia pentru a respecta aceste specificaţii, exact cum ar face pentru NeTEx, SIRI sau GTFS, care sunt de asemenea standarde pe zone specifice. Pentru claritate le enumeram si evidentiem ca ele sunt standarde care au zone de functionalitate si aplicabilitati diferite pentru componentele necesare in aceasta achizitie: - Zona de smart city / interoperabilitate generală: FIWARE, SynchroniCity. - Zona de transport public - standard europene propuse de CEN (Comitetul European de Standardizare): NeTEx, SIRI, OpRa, OJP. - Zona de transport public - standarde de facto internaţionale : GTFS, GTFS-RT. 1. FIWARE • Ce este: cadru open-source pentru dezvoltarea de servicii digitale smart city. • Aplicaţii: interoperabilitate orizontală (API-uri NGSI-LD, context broker, IoT agents). • Domeniu: platforme urbane, integrarea diferitelor verticale (transport, mediu, siguranţă). 2. SynchroniCity • Ce este: iniţiativă Horizon 2020 pentru interoperabilitatea oraşelor inteligente, bazată pe MIMs (Minimal Interoperability Mechanisms). • Aplicaţii: modele comune de date şi puncte de interoperabilitate pentru servicii urbane. • Domeniu: smart cities, integrarea transfrontalieră a aplicaţiilor urbane. 3. NeTEx (Network Timetable Exchange) • Ce este: standard CEN pentru schimbul electronic de orare şi structuri de reţea de transport. • Aplicaţii: publicarea datelor de orar şi reţea către platforme naţionale/europene. • Domeniu: transport public (static data, orare, reţele, tarife). 4. SIRI (Service Interface for Real Time Information)  • Ce este: standard CEN pentru schimbul de informaţii în timp real privind transportul public. • Aplicaţii: estimări timp sosire, incidente, localizare vehicule. Domeniu: transport public (real-time passenger info). Pagina 71 din 95

5. OpRa (Operating Raw Data) • Ce este: standard CEN pentru colectarea datelor brute operaţionale. • Aplicaţii: analiza performanţei, raportări, evaluări statistice. • Domeniu: transport public (KPI, statistici operaţionale). 6. OJP (Open Journey Planning) • Ce este: standard CEN pentru planificarea interoperabilă a călătoriilor multimodale. • Aplicaţii: integrarea datelor de la mai mulţi operatori într-un singur journey planner. • Domeniu: transport multimodal şi transfrontalier. 7. GTFS (General Transit Feed Specification) • Ce este: standard „de facto" dezvoltat iniţial de Google. • Aplicaţii: publicarea datelor statice despre reţelele de transport (rute, staţii, orare). • Domeniu: transport public, utilizat global. 8. GTFS-RT (General Transit Feed Specification - Realtime) • Ce este: extensia în timp real a GTFS. • Aplicaţii: actualizarea datelor privind sosiri/plecări, vehicule, incidente. • Domeniu: transport public (real-time data exchange). • Spre deosebire de un produs comercial, standardele open-source garantează tocmai neutralitatea tehnologică şi evitarea dependenţei de un singur furnizor. Din acest motiv FIWARE şi SynchroniCity au fost promovate de Comisia Europeană - pentru a asigura că administraţiile locale nu vor fi captive unui vendor unic, ci pot combina soluţii de la furnizori diferiţi în cadrul aceluiaşi ecosistem. • Contestatoarea invocă faptul că există şi alte standarde europene (NeTEx, SIRI, GTFS etc.). Această observaţie este irelevantă, pentru că şi caietul de sarcini le include explicit (Secţiunea 4.2.5 - Standarde şi normative de respectat). Autoritatea contractanta nu a exclus aceste standarde, ci le-a completat cu FIWARE/SynchroniCity pentru a asigura interoperabilitatea nu doar în domeniul transportului, ci şi cu alte servicii smart city (video analytics, mediu, siguranţă publică). • În plus, autoritatea contractanta are deja implementate soluţii bazate pe FIWARE (ex. proiectul de video analytics). Alegerea continuării pe aceeaşi arhitectură este o decizie strategică justificată, pentru a asigura integrarea şi reutilizarea rezultatelor investiţiilor anterioare. A nu face asta ar fi o risipă de resurse publice şi ar genera fragmentare tehnologică. Concluzie: Impunerea utilizării FIWARE şi SynchroniCity nu restrânge concurenţa, ci dimpotrivă, asigură deschidere, interoperabilitate şi continuitate strategică. Orice operator are acces liber la aceste specificaţii şi le poate implementa fără bariere, astfel încât cerinţa autoritatii contractante este nu doar legală şi proporţională, ci şi în deplin acord cu principiile europene de evitare a captivitatii tehnologice si dependenta de un furnizor şi de construire a unor ecosisteme digitale deschise. Contrar celor susținute de contestestatoare, a construi arhitectura în jurul FIWARE/SynchroniCity nu înseamnă impunerea unei soluţii comerciale, ci alinierea la un cadru tehnic deschis, recunoscut la nivel european. Aceste standarde permit integrarea cu alte servicii urbane şi evită fragmentarea tehnologică. Împrejurarea că autoritatea contractantă a solicitat ofertanților ca arhitectura să fie construită „în jurul" FIWARE şi SynchroniCity nu înseamnă impunerea unei soluţii proprietare, ci alinierea la un set de specificații, cum ar fi interfețe, API-uri, modele de date şi mecanisme de interoperabilitate care sunt deja recunoscute la nivel european şi implementate în oraşe, cerința alegerii continuării pe aceeaşi arhitectură este o decizie strategică justificată, pentru a asigura integrarea şi Pagina 72 din 95

reutilizarea rezultatelor investiţiilor anterioare (autoritatea contractanta are deja implementate soluţii bazate pe FIWARE (ex. proiectul de video analytics). Consiliul achiesează la argumentele achizitoarei, în stabilirea acestei finalități se are în vedere că autoritatea contractantă trebuie să evalueze fiecare procedură de achiziţie publică, în parte, şi să aleagă modalitatea de organizare a procedurii aplicabile şi de întocmire a documentaţiei de atribuire, care să asigure cel mai bine atingerea scopului urmărit prin încheierea contractului şi o utilizare cât mai eficientă a fondurilor publice. Așadar revine autorităţii contractante rolul de a asigura un echilibru între interesele sale (în condiţiile în care regula este aceea a priorităţii interesului public, în dauna celui privat, al operatorilor economici) și modalitatea de atingere a acestora - ceea ce presupune stabilirea obiectului contractului, a documentaţiei şi a întregii proceduri de atribuire precum şi respectarea legislaţiei în materia achiziţiilor publice. Aceeași concluzie de netemeinicie va fi reținută și vizavi de susținerile contestatoarei potrivit cărora din Secţiunea 14 Factori de evaluare din Caietul de Sarcini, pct. 2.1 rezultă că se va acorda punctajul maxim din perspectiva acestui criteriu de evaluare doar dacă propunerea tehnică include integrarea standardelor FIWARE şi SynchroniCity în centrul arhitecturii, favorizând astfel în mod nejustificat ofertanţii deja integraţi în aceste sisteme şi distorsionând concurenţa. Așa cum a fost anterior reținut prioritar este interesul public unde așteptările și nevoile sunt foarte mari, astfel că se încheie contractul pentru realizarea unor sarcini ale interesului public. În acest context, având în vedere că prin contractul administrativ administrația publică (sau entitățile asimilate) își realizează o parte din sarcinile sale, se consideră că regimul juridic aplicabil acestor contracte este unul exorbitant, de drept public. Recapitulând ansamblul considerenteror anterior expuse, Consiliul constată faptul că cerinţa de integrare nu vizează un produs comercial anume, ci respectarea unor standarde europene de interoperabilitate, promovate prin FIWARE şi SynchroniCity (documentaţia şi API-urile sunt publice şi accesibile oricărui furnizor, fără constrângeri de licenţiere). A construi arhitectura în jurul FIWARE/SynchroniCity nu înseamnă impunerea unei soluţii comerciale, ci alinierea la un cadru tehnic deschis, recunoscut la nivel european. Aceste standarde permit integrarea cu alte servicii urbane şi evită fragmentarea tehnologică. Așa cum a susținut și achizitoarea, conform art. 156 din Legea nr. 98/2016, autoritatea contractantă aplică principiul echivalenţei, iar menţiunea expresă „sau echivalent" este implicit aplicabilă în cazul specificării unor standarde tehnice deschise, astfel că orice ofertant poate propune soluţii echivalente, cu condiţia să asigure aceleaşi mecanisme de interoperabilitate. Autoritatea contractanta nu exclude echivalenţa, ci solicită alinierea la un set de specificaţii deschise. Orice operator poate adapta soluţia sa pentru a respecta aceste standarde, Pagina 73 din 95

exact cum se întâmplă cu NeTEx, SIRI sau GTFS. Cerinţa nu favorizează un furnizor, ci promovează interoperabilitatea reală. Pentru a evita orice interpretare cu privire la obligațiile ofertanților ori limitele de evaluare ale achizitoarei din acest punct de vedere, Consiliul apreciază că se impune ca autoritatea contractantă să publice explicațiile/precizările aduse pe calea punctului de vedere vizavi de aspectele reclamate. 5) Critica formulată de .. SA (pct. V din contestație) vizează faptul prin documentaţia de atribuire se solicită un număr semnificativ de integrări cu aplicaţii software şi echipamente externe existente, precum şi furnizarea unor funcţionalităţi viitoare si integrări cu sisteme "viitoare", fără furnizarea documentaţiei tehnice de integrare sau a oricăror alte detalii tehnice. Contestatoarea susține că, prin documentaţia de atribuire, se solicită o serie de integrări cu aplicaţii software şi echipamente externe existente (software-ul instalat pe echipamentele existente şi cu software- ul de management a traficului existent) și o serie de integrări cu sisteme viitoare, precum şi integrarea în cadrul ofertei a unor funcţionalităţi viitoare, respectiv: - în cadrul Secţiunii 4.2 Descrierea Sistemului din Caietul de sarcini - Subsecţiunea 4.2.1 Integrarea funcţionalităţi lor sistemului de e-Ticketing in soluţiile cloud scalabile - pct. 2. Componenta de e-Monitorizare si Informare calatori (e-MIC) - Analiza şi controlul traficului se menţionează: Analiza şi controlul traficului prin monitorizarea şi controlul traficului (integrare cu ultimul upgrade la platforma Omnia/Swarco); - în cadrul Secţiunii 5 Componenta de taxare/procesare de plăţi (e-TAX) din Caietul de sarcini - Subjecţiunea 5.1 Descrierea generala a Platformei se menţionează: Având in vedere vehicidele noi din flota STPT recepţionate in ultimii 5 ani (40 tramvaie Bozankaya, 44 autobuze electrice Karsan) si cele 33 troleibuze si 30 autobuze electrice 1 Om in curs de achiziţie precum si dotarea acestora cu Calculatoare de bord, validatoare si senzori de numărare, Platforma de e-Taxare (e-TAX) va integra echipamentele (Calculatoare de bord, validatoare EMV si senzori de numărare) de pe aceste vehicule; - în cadrul Secţiunii 6 Platforma e-Monitorizare si Informare calatori (e-MIC) din Caietul de sarcini se precizează că: Aceasta platforma va furniza cel puţin funcţionalitatea existenta pe aplicaţia ... De asemenea, în cadrul Subsecţiunii 6.1 Arhitectura Platformei e- Monitorizare si Informare se precizează următoarele cerinţe de integrare: - 6.1.2 Modul Echipamente îmbarcate - 6.1.2.1 MCM/OBC: Cerinţe tehnice minime: Interconectare cu sistemul OMNIA aflat la centrul de trafic al Primăriei Timişoara si posibilitate de extindere pentru sisteme dedicate managementului de trafic; 6.1.4 Modulul Publicitate (MP) - Modulul de Publicitate va oferi posibilitatea de conectare SECURIZAT din backoffice către TOATE sistemele existente de publicitate din mijloacele de transport in comun, a panourilor de informare calatori din staţii, sau a Display- urilor LCD de informare in staţii ce fac parte din reţeaua .. (...). Pe de altă parte, prin documentaţia de atribuire se solicită o serie de integrări cu sisteme viitoare, precum şi integrarea în cadrul ofertei a unor funcţionalităţi viitoare, fără a fi prezentate detalii tehnice suficiente (i.e. acces la documentaţia de integrare a sistemului, standardele de comunicare), care să permită ofertanţilor să evalueze fezabilitatea tehnică a integrării sau evaluarea costurilor reale ce urmează să fie suportate. - In cadrul Secţiunii 5 Componenta de taxare/procesare de plăţi (e-TAX) din Caietul de sarcini se menţionează că: Ofertantul declarat câştigător va asuma dezvoltarea sistemului de e-TAX care face obiectul prezentei achiziţii si in viitor, fără costuri suplimentare pentru Autoritatea Pagina 74 din 95

Contractanta, oferind soluţii de API care sa permită cel puţin următoarele integrări, fără a se limita la acestea:integrarea de noi echipamente hardware , inclusiv definirea unor cerinţe de integrabilitate pentru acestea; integrarea cu alte sisteme de ticketing de tip ABT, in spiritul interoperabilităţii intre sisteme. - în cadrul Subsecţiunii 5.4 Zona de Front Office - 5.4.5 Platforma web si aplicaţia mobila se menţionează că: Se va tine cont de dezvoltări ulterioare si de interconectări cu sistemele de biciclete, „ride sharing" si alte modalităţi de călătorie ce pot fi utilizate, gen trenuri regionale, etc. Din economia celor redate se reține faptul că autoarea contestației susţine că documentaţia de atribuire impune cerinţe excesive şi neclare, întrucât solicită integrarea cu aplicaţii şi echipamente deja existente (.., Omnia/Swarco, ERP ASSIS, totemuri, ecrane din vehicule), precum şi cu posibile sisteme viitoare (ride-sharing, trenuri regionale etc.), fără a furniza documentaţia tehnică necesară. Acesta invocă riscul restrângerii concurenţei şi al avantajării furnizorilor actuali, în temeiul art. 50 şi art. 155 alin. (6) din Legea nr. 98/2016 privind proporţionalitatea şi tratamentul egal. Față de cele reclamate contestatoarea solicită: Pentru aplicaţiile software cu care se solicită integrarea, vă rugăm să obligaţi Autoritatea contractantă să pună la dispoziţia tuturor operatorilor economici, de la momentul întocmirii ofertei, următoarele informaţii/date: - Funcţionalităţile tehnice detaliate ale acestor aplicaţii software; - Manuale de utilizator, manuale de administrare; - Documentaţia de integrare; - Protocoale/ standarde de comunicaţie acceptate; - API-uri (Application Programming Inter/ace); - Descrierea modalităţilor de realizare a schimbului de informaţii între aplicaţiile existente şi sistemele solicitate prin Caietul de Sarcini sau orice alte documente relevante sau necesare integrării Pentru fiecare din echipamentele cu care se solicita integrarea (i.e. panouri din reţea .., validatoare, computere de bord, sisteme de numărare), vă rugăm să obligaţi Autoritatea contractantă să pună la dispoziţia tuturor operatorilor economici, de la momentul întocmirii ofertei, a cel puţin următoarelor informaţii: - Codurile produselor şi denumirea producătorului; - Versiunile de Firmware; - Specificaţii tehnice detaliate de produs hardware şi software; - Manuale de utilizator, descrieri şi schiţe; - Manuale de administrare; - Documentaţii de integrare; - Protocoale de comunicaţii utilizate de echipament pentru schimbul de date cu aplicaţii terţe; - Datele necesare pentru realizarea schimbului de informaţii între echipamentele solicitate în prezenta procedură cu echipamentele existente/în curs de implementare sau orice alte documente relevante sau necesare integrării. Față de susținerile și solicitările contestatatoarei, autoritatea contractantă formulează apărări punctuale: 1. Integrarea cu .. Achiziţia anterioară pentru .. a avut două componente distincte: • (a) Aplicaţia software .., care se doreşte înlocuită integral prin actualul proiect. Documentaţia ei nu este necesară, întrucât funcţionalitatea de planner/router este deja aproape un standard internaţional oferit prin API-uri publice de aplicaţii precum Google Maps şi Waze. Mai mult, autoritatea contractanta are parteneriat activ cu aceste platforme, ceea ce permite integrarea directă în ecosistemul şi comunitatea lor globală de soluţii. • (b) Ecranele şi totemurile montate în staţii şi vehicule sunt echipamente standard, cu sistem de operare Android. Integrarea lor se face conform API-urilor publice Pagina 75 din 95

disponibile în ecosistemul Android/Google. Fişele tehnice ataşate (Dahua DHI-LDV65-EAO400K pentru totemuri, panouri LCD Rockchip RK3568 pentru vehicule) confirmă că aceste echipamente sunt deschise, rulează Android/Linux şi acceptă API-uri şi aplicaţii terţe. Remediere propusă prin clarificare din oficiu pe SEAP la documentatia achizitiei: Pentru a înlătura orice incertitudine legată de disponibilitatea informaţiilor tehnice referitoare la echipamentele de afişaj (respectiv totemurile din staţii şi ecranele din mijloacele de transport public), autoritatea contractantă va publica, în SEAP, o clarificare din oficiu care va include fişele tehnice corespunzătoare acestor echipamente. Această măsură are ca scop garantarea transparenţei, asigurarea unui acces echitabil la informaţii pentru toţi operatorii economici interesaţi şi respectarea principiilor concurenţei loiale prevăzute de Legea nr. 98/2016. 2. Integrarea cu sistemul Omnia/Swarco Autoritatea contractantă nu deţine în prezent API-urile sistemului Omnia folosit actualmente datorită faptului că acest lucru nu se regăseşte ca sarcină contractuală. Totodată, ofertantul câştigător va fi pus în contact cu dezvoltatorul sistemului de trafic management (Swarco) pentru un schimb cât mai facil de informaţii şi date. Pentru a evita ambiguităţi şi sarcini disproporţionate, autoritatea contractanta va limita integrarea la maximum 20 de funcţionalităţi (endpoint-uri), stabilite de comun acord cu operatorul selectat. 3. Integrarea cu ERP (ASSIS) Se solicită doar posibilitatea tehnică de integrare prin standarde larg utilizate (HTTPS, JSON/XML, OAuth 2.0, OpenAPI/Swagger, versionare, audit, sandbox). Ca şi în cazul Omnia, integrarea va fi limitată la maximum 20 de endpoint-uri, stabilite de comun acord. 4. Integrarea cu sisteme viitoare Această cerinţă nu implică integrarea efectivă cu sisteme care nu există în prezent. Se solicită doar ca arhitectura tehnică a soluţiei să fie scalabilă, deschisă şi interoperabilă, în vederea posibilelor extinderi ulterioare (ex. FIWARE, SynchroniCity). Această abordare este conformă cu bunele practici europene privind evitarea dependenţei de furnizori unici („vendor lock-in") şi reducerea costurilor viitoare pentru autoritatea contractantă. Concluzia la care ajunge achizitoarea este aceea că cerinţele sunt proporţionale şi justificate de obiectivul proiectului care constă în construirea unei platforme integrate şi interoperabile. Astfel nu se creează avantaje pentru furnizorii existenţi, întrucât: - aplicaţia .. este înlocuită, nu integrată; - ecranele şi totemurile sunt Android standard, documentaţia fiind publică (cu documentatiile fiselor tehnice atasat la raspuns); - Omnia şi ASSIS vor expune un set limitat de API-uri standardizate; - integrarea cu sisteme viitoare vizează doar capabilitatea arhitecturii. Urmare a luării la cunoștința despre precizările achizitoarei din punctul de vedere, contestatoarea este în continuare nemulțumită de faptul că se solicită un număr semnificativ de integrări cu aplicaţii software si echipamente externe existente, precum si furnizarea unor funcţionalităţi viitoare si integrări cu sisteme " viitoare", fără furnizarea documentaţiei tehnice de integrare sau a oricăror alte detalii tehnice, menținând solicitările adresate mai sus redate. Și față de aceste susțineri, autoritatea formulează apărări punctuale pe care Consiliul le apreciază credibile și concludente prin raportare la obiectul și specificul contractului supus procedurii, respectiv: Pagina 76 din 95

Critica .. privind lipsa documentaţiei tehnice pentru integrare este nefondată. Documentaţia nu solicită integrarea completă în etapa de ofertare, ci doar demonstrarea capacităţii soluţiei de a fi integrată. Pentru fiecare sistem menţionat (.., Omnia, ERP), autoritatea contractanta a precizat clar că integrarea se va face pe baza unor API-uri standard, cu un număr limitat de endpoint-uri, iar pentru echipamentele existente vor fi publicate fişele tehnice în SEAP. Afirmaţia .. că punctele sunt tratate separat ignoră faptul că autoritatea contractanta a abordat integrările într-un mod unitar, proporţional şi etapizat. Documentaţia nu impune integrarea simultană cu toate sistemele, ci stabileşte cerinţe distincte pentru fiecare categorie, în funcţie de disponibilitatea tehnică şi de stadiul fiecărui sistem. Referirea .. la aplicatia de planner ca nefiind un standard internaţional este irelevantă. Autoritatea contractanta nu solicită integrarea cu aplicaţia .., ci înlocuirea acesteia cu API-uri publice (Google Maps, Waze), care sunt standardizate de facto şi utilizate la nivel global. Acestea oferă funcţionalitatea de planificare a rutelor într-un mod interoperabil şi scalabil. .. invocă standardele GTFS, NeTEx şi OJP ca fiind cele reale. Autoritatea contractanta nu le exclude, ci le cere si ea in caietul de sarcini ca parte din ecosistemul de integrare pe funtionalitatea de mobilitate. Asadar, documentaţia nu numai ca permite utilizarea acestor standarde ci le si cere, iar cerinţa de interoperabilitate este formulată generic, tocmai pentru a permite flexibilitate tehnologică. La fel cum propune FIWARE si Syncronicity pentru functionalitatea de smartcity. Critica privind fişele .. promise, dar nepublicate, se putea rezolva prin clarificare pe SEAP. Documentatia este relativ standard pentru tehnologia de display (ecrane) din ziua de azi si se regasesc usor pe internet. Autoritatea contractanta a identificat fişele tehnice relevante (Dahua, Rockchip) şi s-a angajat să le publice în SEAP prin clarificare din oficiu. Această măsură asigură acces egal la informaţii pentru toţi operatorii economici. Afirmaţia .. că fişele nu au fost efectiv ataşate ignoră angajamentul Autoritatea contractanta de a le publica oficial. Documentaţia nu impune integrarea fără acces la specificaţii, ci prevede clar că acestea vor fi disponibile în mod transparent, înainte de termenul limită de ofertare. .. recunoaşte că datele tehnice sunt necesare, iar autoritatea contractanta confirmă acest lucru prin publicarea fişelor şi prin definirea cerinţelor de integrare. Nu există o contradicţie, ci o convergenţă de poziţii, ceea ce demonstrează că documentaţia este echilibrată şi corectă. Critica privind lipsa informaţiilor minime pentru integrare este contrazisă de specificaţiile autoritatii contractante: pentru ERP şi Omnia se definesc cerinţe standard (HTTPS, JSON/XML, OAuth 2.0.), iar pentru echipamentele .. se oferă fişe tehnice. Acestea sunt suficiente pentru demonstrarea capacităţii de integrare. Afirmaţia că lipsa informaţiilor restrânge concurenţa este eronată. Documentaţia nu impune integrarea completă, ci doar capacitatea de a integra. Prin publicarea fişelor şi definirea cerinţelor API, autoritatea contractanta asigură acces egal şi evită orice avantaj competitiv nejustificat .. susţine că PMT nu are API-urile Omnia. Autoritatea contractanta confirmă acest lucru, dar precizează că ele vor fi solicitate la următorul upgrade şi puse la dispoziţia câştigătorului. Integrarea este limitată la 20 de endpoint-uri, ceea ce menţine proporţionalitatea şi evită costuri excesive. Obligaţia de informare corectă este respectată. Autoritatea contractanta a comunicat public stadiul fiecărui sistem şi a precizat ce informaţii vor fi disponibile. Procedura nu favorizează niciun operator, ci oferă un cadru transparent şi echitabil pentru toţi participanţii. Afirmaţia că procedura a fost demarată prematur este nefondată. Documentaţia reflectă stadiul actual al sistemelor şi defineşte cerinţele în mod proporţional. Pentru Omnia, integrarea se va face ulterior, iar pentru celelalte sisteme se oferă informaţii tehnice relevante. Critica privind ERP-ul ASSIS ignoră faptul că autoritatea contractanta a definit cerinţe clare (OpenAPI, OAuth 2.0 etc.) şi a limitat numărul de endpoint-uri. Aceste măsuri asigură o integrare realistă, fără a impune dezvoltări speculative sau costuri disproporţionate. .. recunoaşte că integrarea cu sisteme viitoare nu este efectivă, ci doar o cerinţă de capabilitate. Autoritatea contractanta confirmă acest lucru şi solicită doar ca arhitectura să fie scalabilă şi deschisă, pentru a permite evoluţia ulterioară a sistemului. Pentru acest motiv Pagina 77 din 95

autoritatea contractanta a recurs la cererea unor standarde europene ca cerinte si specificatii tehnice in aceasta licitatie (vezi standardele FIWARE, Synchonicity si cele pe mobilitate). Solicitarea .. de a preciza cerinţe punctuale pentru sisteme viitoare este contrară principiului de flexibilitate. Documentaţia nu impune dezvoltări speculative, ci doar o viziune arhitecturală deschisă, ceea ce este o practică standard în proiectele IT complexe. Eliminarea integrărilor fără documentaţii, aşa cum solicită .., ar limita capacitatea de evoluţie a sistemului. Autoritatea contractanta nu impune integrarea completă, ci doar capacitatea de a integra, pe baza unor standarde deschise şi echipamente compatibile. Informarea tehnică integrală este asigurată prin publicarea fişelor, definirea cerinţelor API şi clarificările din oficiu. Documentaţia nu ascunde informaţii, ci le pune la dispoziţie în mod transparent, în conformitate cu principiile achiziţiilor publice. Pentru aplicaţiile software, autoritatea contractanta a definit cerinţe standard (OpenAPI, JSON/XML, OAuth 2.0) şi a precizat că integrarea se va face cu un număr limitat de funcţii. Aceste informaţii sunt suficiente pentru elaborarea unei oferte conforme. Pentru echipamentele existente, autoritatea contractanta a identificat fişele tehnice relevante şi s-a angajat să le publice în SEAP. Acestea confirmă compatibilitatea cu Android şi API-uri terţe, ceea ce garantează interoperabilitatea şi evitarea blocajelor tehnologice. Concluzie pentru Subcapitolul II.5 Integrarea cu aplicaţii, echipamente existente şi sisteme viitoare 1. .. (aplicaţie + echipamente) • Aplicaţia software .. nu se mai integrează, ci se înlocuieşte. Funcţionalitatea de planner/router este deja disponibilă prin API-uri publice (Google Maps, Waze), la care autoritatea contractanta are parteneriat şi acces. Acestea sunt standardizate de facto şi utilizate la nivel global. • În privinţa echipamentelor (ecrane pentru totemuri din staţii şi ecrane din vehicule), autoritatea contractanta a identificat şi anexat fişele tehnice oficiale (Dahua DHI- LDV65-EA0400K, Rockchip RK3568) care arată că sunt echipamente Android standard, deschise, ce acceptă aplicaţii şi API-uri terţe. autoritatea contractanta s-a angajat să publice aceste fişe şi în SEAP, prin clarificare din oficiu, astfel încât toţi operatorii economici să aibă acces egal la informaţiile tehnice. 2. Omnia/Swarco • API-urile nu au fost livrate în contractul iniţial şi nu se află în prezent la dispoziţia autoritatii contractante. Ele vor fi solicitate expres la următorul upgrade Omnia, printr-o procedură separată, şi vor fi puse la dispoziţia câştigătorului. • Pentru simplitate şi eficienţă, integrarea va fi limitată la un set de maximum 20 endpoint- uri (functii de integrat), stabilite de comun acord cu autoritatea contractanta, pentru a evita costuri excesive şi pentru a menţine proporţionalitatea. 3. ERP (ASSIS) • Autoritatea contractanta a precizat deja cerinţe minimale (HTTPS, JSON/XML, OAuth 2.0, OpenAPI/Swagger, sandbox, audit, versionare), si propune limitarea numărului la maxim 20 de endpoint-uri (functii de integrat), pentru a evita costuri excesive şi pentru a menţine proporţionalitatea. 4. Sisteme viitoare • Autoritatea contractanta nu solicită integrarea efectivă cu sisteme inexistente. • Cerinţa este ca arhitectura propusă să fie scalabilă şi deschisă, pentru a preveni captivitatea tehnologica si dependenta de un singur furnizor, şi a permite integrarea ulterioară a unor servicii noi (ex. ride-sharing, trenuri regionale). • Aceasta este o cerinţă de capabilitate tehnică şi viziune arhitecturală, nu de execuţie anticipată. Se are în vedere că autoritatea contractantă trebuie să evalueze fiecare procedură de achiziţie publică, în parte, şi să aleagă modalitatea de organizare a procedurii aplicabile şi de întocmire a documentaţiei de atribuire, care să asigure cel mai bine atingerea scopului urmărit prin încheierea contractului şi o utilizare cât mai eficientă a fondurilor publice. Așadar, revine autorităţii contractante rolul de a asigura un echilibru între interesele sale (în condiţiile în care regula este aceea a Pagina 78 din 95

priorităţii interesului public, în dauna celui privat, al operatorilor economici) și modalitatea de atingere a acestora - ceea ce presupune stabilirea obiectului contractului, a documentaţiei şi a întregii proceduri de atribuire precum şi respectarea legislaţiei în materia achiziţiilor publice. Consiliul achiesează la argumentele aduse de achizitoare în favoarea impunerii cerințelor de integrare reclamate, pe considerentul că documentaţia nu solicită integrarea completă în etapa de ofertare, ci doar demonstrarea capacităţii soluţiei de a fi integrată, folosind standarde şi echipamente deschise. Pentru a evita orice interpretare cu privire la obligațiile ofertanților ori limitele de evaluare ale achizitoarei din acest punct de vedere, Consiliul apreciază că se impune ca autoritatea contractantă să publice explicațiile/precizările aduse pe calea punctului de vedere vizavi de aspectele reclamate. Pentru echipamente (totemuri/ecrane) fişele tehnice solicitate vor fi publicate în SEAP având în verdere achiesarea achizitoarae la solicitarea adresată. Pentru Omnia şi ASSIS integrarea este definită generic prin API-uri standard, cu un set limitat de endpoint-uri. Pentru sisteme viitoare cerinţa este doar ca arhitectura să fie scalabilă şi interoperabilă, astfel că la momentul ofertării nu se solicită integrarea completă, a viitoarelor functionalitati care nu sunt obiectul acestei achizitii, ci se solicită doar demonstrarea capacităţii soluţiei de a fi integrată, folosind standarde şi echipamente deschise. În raport de cele mai sus reținute, Consiliul, având în vedere faptul că achizitoarea a achiesat la solicitările .. SA și a precizat că a identificat fişele tehnice relevante (Dahua, Rockchip) şi s-a angajat să le publice în SEAP prin clarificare din oficiu, Consiliul urmează să admită criticile și să oblige autoritatea contractantă să publice în SEAP aceste Fişe Tehnice (Dahua DHI-LDV65-EAO400K pentru totemuri, panouri LCD Rockchip RK3568 pentru vehicule) în vederea informării tuturor operatorilor economici interesaţi de participarea la procedură, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. 6) Critica formulată de .. SA ( pct. VI din contestație) vizează faptul că documentaţia de atribuire cuprinde cerinţe tehnice care nu au legătură cu obiectul contractului de achiziţie publică, care exced obiectul acestuia sau care sunt disproporţionate prin raportare la obiectivele acestuia, respectiv: - în primul rând, în Secţiunea 5 Componenta de taxare/procesare de plăţi (e-TAX) din Caietul de sarcini - Subsecţiunea 5.2 Cardurile contactless, se menţionează următoarele specificaţii fizice şi chimice ale Suportului de card: dimensiuni card: conform ISO 7810ID-1 temperatura de funcţionare: -25°C +70°C testare conform cu standardul ISO 10373-6. Cu toate acestea, proiectul care face obiectul procedurii de atribuire nu cuprinde furnizarea de cârduri, astfel încât vă rugăm să obligaţi Autoritatea contractantă să elimine această cerinţă. Pagina 79 din 95

- în al doilea rând, în cadrul aceleiaşi Subsecţiuni din Caietul de sarcini se menţionează: "Având in vedere faptul NXP deţine drepturile exclusive asupra tehnologiei MIFARE, si existenta a foarte multe clone nelicentiate si care conţin chiar instrucţiuni de tip "backdoor", ofertantul trebuie sa aiba certificat acordat de Arsenal Testhouse GmbH sau alta instituţie independenta conform ISO 17025, acceptata de către NXP " Astfel, se solicită prin documentaţia de atribuire ca ofertantul sa fie certificat de laboratoare independente cum ar fi Arsenal Testhouse GmbH, cu toate că exclusiv producătorii de cârduri dotate cu card NXP pot fi certificaţi de astfel de laboratoare. În consecinţă, această cerinţă se impune a fi eliminată din documentaţia de atribuire, întrucât: - Pe de o parte, furnizarea de cârduri cu cip NXP nu face obiectul prezentei proceduri de achiziţie publică; Pe de altă parte, cerinţa limitează în mod nejustificat accesul egal al operatorilor economici care nu sunt şi producători de cârduri la procedura de atribuire; - în al treilea rând, în Secţiunea 8 Cloud Hosting - Subsecţiunea 8.3 Minimul de resurse cloud - 8.3.2 Cerinţe la nivel de DataCenter se menţionează următoarea cerinţă: Ofertanţii vor transmite o descriere detaliata a locaţiei data center-ului pentru serviciile de Cloud (inclusiv adresa) si a facilităţilor disponibile care sa corespunda cel puţin elementelor solicitate. Pentru fiecare cerinţă ofertantul va detalia producătorul, tipul si modelul echipamentelor utilizate, numărul si amplasamentul acestora. Curentul electric consumat de echipamentele necesare va fi inclus in oferta financiara transmisa Vă rugăm să obligaţi Autoritatea contractantă să excludă această cerinţă din Documentaţia de atribuire, întrucât: - Pe de o parte, prin Caietul de sarcini se solicită furnizarea unor servicii de găzduire şi stocare a aplicaţiilor software furnizate într-un Cloud. Autoritatea cere informaţii care nu sunt accesibile niciunui ofertant rezonabil, întrucât furnizorii de servicii Cloud nu dezvăluie niciodată astfel de detalii tehnice (producător, tip, model, număr, amplasament echipamente). Astfel, cerinţa limitează în mod nejustificat accesul egal al operatorilor economici la procedura de atribuire; Pe de altă parte, cerinţa nu este proporţională prin raportare la obiectivul achiziţiei, în condiţiile în care sunt solicitate servicii de tip Cloud, accentul trebuie să fie pus pe caracteristicile serviciului (securitate, disponibilitate, certificări), nu pe inventarul fizic al echipamentelor, acestea fiind lipsite de orice relevanţă. Referitor la cerința privind cardurile contacless, Consiliul reține argumentele aduse de achizitoare în replică la cele reclamate, respectiv: Menţionarea parametrilor cardurilor (ex.: compatibilitate ISO/IEC 14443 A/B, timpi de răspuns, suport anti-coliziune, capabilităţi de criptare, gestionarea cheilor) este strict necesară pentru dimensionarea corectă a validatoarelor (HW + firmware), definirea interoperabilităţii cu titlurile de călătorie şi prevenirea riscului de achiziţie a unor validatoare care nu pot citi suporturile planificate în proiect (card, token, NFC). Cerinţa este legată de obiectul contractului (validare e-ticketing), proporţională şi formulată cu neutralitate tehnologică, fiind totodată însoţită de sintagma „sau echivalent" conform specificaţiilor din Caietul de Sarcini. Specificaţiile tehnice au fost concepute astfel încât să nu restrângă concurenţa şi in acelaşi timp să urmărească performanţa necesară. Pagina 80 din 95

Așadar, așa cum a susinut și achizitoarea, menţiunile privind cardurile nu „condiţionează" piaţa, ci stabilesc reperul de performanţă pentru validatoare şi interfaţa lor cu suporturile de călătorie, respectând proporţionalitatea şi transparenţa. Ulterior luării la cunoștință despre precizările achizitoarei, contesatatoarea a susținut că întrucât răspunsul formulat nu rezolvă neclaritatea documentaţiei de atribuire privind obiectul achiziţiei, vă rugăm să obligaţi Autoritatea contractantă să adopte măsuri de remediere prin care să precizeze în mod clar şi fără echivoc faptul că în prezenta procedură nu vor fi achiziţionate carduri contactless, iar la elaborarea ofertei nu va fi necesar în nici un fel să fie făcute referiri la aceste carduri. Cu ocazia formulării concluziilor scrise autoritatea contractantă a precizat următoarele: Autoritatea contractanta a precizat clar că aceste detalii sunt necesare pentru dimensionarea corectă a validatoarelor. Fără aceste informaţii, există riscul achiziţiei unor echipamente incompatibile cu suporturile deja utilizate de cetăţeni. Cerinţa este justificată tehnic şi urmăreşte interesul public. .. solicită clarificarea faptului că nu se achiziţionează carduri. Autoritatea contractanta a formulat cerinţele în mod neutru, fără a impune livrarea de carduri, ci doar compatibilitatea cu cele existente. Această abordare este standard în proiectele de modernizare a sistemelor de validare. Consiliul, având în vedere faptul că achizitoarea a achiesat la solicitările .. SA potrivit cărora în prezenta procedură nu vor fi achiziţionate carduri contactless, respectiv: 1. Carduri contactless (specificaţii fizice/chimice) • Obiectul contractului nu este achiziţia de carduri, ci validatoarele trebuie dimensionate şi testate corect pentru a recunoaşte suporturile deja existente (carduri MIFARE, sau tehnologii smartphone de tip NFC, mobile wallet). • De aceea, caietul de sarcini include parametrii ISO/IEC 14443 A/B, timpi de răspuns, capabilităţi de criptare. Nu e o cerinţă de livrare a cardurilor, ci una de interoperabilitate şi continuitate a serviciului public. • Cerinţele sunt neutre şi proporţionale, fiind însoţite de sintagma „sau echivalent". Față de explicațiile aduse de achizitoare, Consiliul urmează să admită criticile și să oblige autoritatea contractantă să publice în SEAP clarificările/precizările aduse pe calea punctului de vedere formulat în vederea informării tuturor operatorilor economici interesaţi de participarea la procedură, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. Referitor la cerința de la Secţiunea 5 Componenta de taxare/procesare de plăţi (e-TAX) din Caietul de sarcini - Subsecţiunea 5.2 Cardurile contactless, se menţionează: "Având in vedere faptul ca NXP deţine drepturile exclusive asupra tehnologiei MIFARE, si existenta a foarte multe clone nelicentiate si care conţin chiar instrucţiuni de tip "backdoor", ofertantul trebuie sa aiba certificat acordat de Arsenal Testhouse GmbH sau alta instituţie independenta conform ISO 17025, acceptata de către NXP". Consiliul reține că argumentele aduse contestatoare în favoarea criticii aduse se bazează pe faptul că prin documentaţia de atribuire se solicită ca ofertantul sa fie certificat de laboratoare independente cum ar fi Arsenal Testhouse GmbH, cu toate că exclusiv producătorii de carduri dotate cu card NXP pot fi certificaţi de astfel de laboratoare. Pagina 81 din 95

Astfel, în aprecierea contestatoarei, această cerinţă se impune a fi eliminată din documentaţia de atribuire, întrucât: - pe de o parte, furnizarea de carduri cu cip NXP nu face obiectul prezentei proceduri de achiziţie publică; - pe de altă parte, cerinţa limitează în mod nejustificat accesul egal al operatorilor economici care nu sunt şi producători de cârduri la procedura de atribuire; Se au în vedere și argumentele aduse de achizitoarea în replică la cele reclamate, respectiv: Răspuns: Autoritatea contractantă a aplicat aceeaşi abordare integrată în mai multe proiecte IT majore anterioare (de ex. portalul cont.primariatm.ro, cloud storage, GIS găzduit în cloud). În toate aceste proceduri s-au precizat cerinţe tehnice de găzduire/operare şi s-a introdus explicit un RACI (Responsabil, Aprobare, Consultat, Informat) pentru claritatea responsabilităţilor între ofertant, furnizorul de infrastructură şi autoritatea contractantă. Rezultatul: proiectele au evitat probleme de integrare sau incompatibilităţi între componente livrate de entităţi diferite şi au asigurat o continuitate operaţională ridicată. Această practică validată este reprodusă şi aici pentru a proteja serviciul public şi investiţia. Juridic, documentaţia de atribuire trebuie să asigure informare completă, corectă şi explicită asupra cerinţelor. Cerinţele de cloud/datacenter şi guvernanţă (RACI) sunt necesare şi proporţionale cu complexitatea proiectului şi cu obligaţiile de securitate şi rezilienţă (NIS2, transpusă prin OUG 155/2024) — managementul riscurilor cibernetice, SLA/disponibilitate, continuitate (RTO/RPO), logare/audit, raportarea incidentelor, securitatea lanţului de aprovizionare. Cerinţele nu urmăresc restrângerea concurenţei. Ulterior, cu ocazia formulării concluziilor scrise, autoritatea contractantă a precizat următoarele: Critica privind certificarea NXP/Arsenal ignoră scopul de securitate al cerinţei. Autoritatea contractanta nu solicită ca ofertanţii să fie producători de carduri, ci ca sistemul să fie compatibil şi securizat pentru cardurile MIFARE. Certificarea independentă este o măsură de protecţie împotriva clonelor vulnerabile. Afirmaţia că doar producătorii pot certifica este inexactă. Cerinţa vizează validatoarele şi infrastructura de citire, nu producţia de carduri. Certificarea de către laboratoare independente (Arsenal Testhouse sau echivalent ISO 17025) este o practică uzuală pentru validarea securităţii cibernetice. .. susţine că cerinţa este nelegală şi restrictivă. În realitate, aceasta este aliniată la Directiva NIS2, care impune controale stricte de securitate pentru infrastructurile critice. Cerinţa nu limitează concurenţa, ci protejează sistemul public împotriva riscurilor de fraudă. Afirmaţia că autoritatea contractanta nu răspunde criticii este nefondată. Documentaţia explică clar scopul cerinţei: securitate cibernetică, compatibilitate cu suporturile existente şi prevenirea riscurilor. Răspunsul este tehnic, justificat şi proporţional cu obiectivele proiectului. Față de explicații achizitoarei, constatându-se faptul că cerinţa vizează validatoarele şi infrastructura de citire, și nu producţia de carduri, astfel cerința privind certificarea NXP/Arsenal al cărei scop este validarea securităţii cibernetice va fi menținută. Referitor la cerința de la Secţiunea 8 Cloud Hosting - Subsecţiunea 8.3 Minimul de resurse cloud - 8.3.2 Cerinţe la nivel de DataCenter se menţionează următoarea cerinţă: Ofertanţii vor transmite o descriere detaliata a locaţiei data center-ului pentru serviciile de Cloud (inclusiv adresa) si a facilităţilor disponibile care sa corespunda cel puţin elementelor solicitate. Pentru fiecare cerinţă ofertantul va detalia producătorul, tipul si modelul echipamentelor utilizate, numărul si amplasamentul acestora. Curentul electric consumat de echipamentele necesare va fi inclus in oferta financiara transmisa. Pagina 82 din 95

Argumentele aduse de autoarea contestației în favoarea eliminării criticii se bazează pe următoarele aspecte: Vă rugăm să obligaţi Autoritatea contractantă să excludă această cerinţă din Documentaţia de atribuire, întrucât: - Pe de o parte, prin Caietul de sarcini se solicită furnizarea unor servicii de găzduire şi stocare a aplicaţiilor software furnizate într-un Cloud. Autoritatea cere informaţii care nu sunt accesibile niciunui ofertant rezonabil, întrucât furnizorii de servicii Cloud nu dezvăluie niciodată astfel de detalii tehnice (producător, tip, model, număr, amplasament echipamente). Astfel, cerinţa limitează în mod nejustificat accesul egal al operatorilor economici la procedura de atribuire; - Pe de altă parte, cerinţa nu este proporţională prin raportare la obiectivul achiziţiei. În condiţiile în care sunt solicitate servicii de tip Cloud, accentul trebuie să fie pus pe caracteristicile serviciului (securitate, disponibilitate, certificări), nu pe inventarul fizic al echipamentelor, acestea fiind lipsite de orice relevanţă. Autoritatea contractantă a explicat rațiunea care a stat la baza cerinței reclamate, respectiv: După cum s-a precizat in Caietul de Sarcini, la punctul 8.3.2 Cerinţe la nivel de DataCenter - Pentru asigurarea securităţii fizice a locaţiei, soluţia oferita in Cloud (DataCenter) trebuie sa respecte cerinţele minime din ORDINUL nr. 489 din 15 iunie 2009 privind normele metodologice de autorizare a centrelor de date, cu toate modificările ulterioare din 2011, emis de Ministerul Comunicaţiilor si Societăţii Informaţionale. Opţiuni acceptate (fără a limita concurenţa pe piaţă): • Cloud public în UE/SEE (certificări ISO 27001/27017/27018, SOC 2 sau echivalent), KMS dedicat, criptare at-rest/in-transit; sau • DataCenter local cu EN 50600/Tier III echivalent, redundanţe N+1 şi SLA garantat. În ambele variante, ofertantul livrează un RACI defalcat pe faze (inception, proiectare, migrare, operare, suport. Ambele opţiuni menţionate mai sus sunt disponibile in Romania. Ulterior luării la cunoștință despre precizările achizitoarei, contesatatoarea a susținut că răspunsul formulat nu rezolvă neclaritatea documentaţiei de atribuire privind obiectul achiziţiei Vă rugăm să constataţi că răspunsul Autorităţii contractante nu adresează criticile formulate, ci invocă generalităţi privind guvernanţa IT şi reglementările NIS2/Ordinul 489/2009, care nu justifică în niciun fel solicitarea explicită de a furniza detalii despre echipamentele fizice (producător, tip, model, număr, amplasament echipamente şi consumul energetic). În realitate, aceste informaţii sunt confidenţiale, inaccesibile operatorilor care utilizează furnizori globali de cloud (AWS, Azure, Google), şi irelevante pentru obiectul contractului. Cu ocazia formulării concluziilor scrise autoritatea contractantă a precizat următoarele: Critica privind cerinţele cloud şi detaliile fizice ale Data Center-ului ignoră contextul digital al autoritatii contractante. Cerinţa nu vizează un inventar complet, ci garanţia că serviciile sunt livrate într-un mediu cloud securizat, conform NIS2 şi Ordinului 489/2009. Afirmaţia că cerinţa este imposibilă şi irelevantă este contrazisă de practica autoritatii contractante T. Aplicaţiile oraşului rulează deja în cloud, iar integrarea noului sistem în acelaşi cont asigură interoperabilitate, securitate şi costuri reduse. Cerinţa este justificată şi proporţională. .. susţine că răspunsul autoritatii contractante conţine doar generalităţi. În realitate, autoritatea contractanta a explicat clar că cerinţa privind cloud-ul vizează alinierea la infrastructura digitală existentă, evitarea dependentei de un singur furnizor sau care nu respecta standarde de cloud/data center neauditabile şi optimizarea costurilor publice. Răspunsul este complet şi justificat. Din examinarea argumentelor aduse de achizitoare în favoarea impunerii detaliilor fizice ale Data Center-ului, Consiliul deternmină temeinicia celor susținute de contestatoare, motivat de faptul că, în Pagina 83 din 95

condiţiile în care sunt solicitate servicii de tip Cloud, accentul trebuie să fie pus pe caracteristicile serviciului (securitate, disponibilitate, certificări), nu pe inventarul fizic al echipamentelor, acestea fiind lipsite de orice relevanţă. Nici din punctul de vedere și nici din răspunsul la concluziile scrise formulat ulterior nu rezultă motivul pentru care achizitoarea a solicitat Pentru fiecare cerinţă ofertantul va detalia producătorul, tipul si modelul echipamentelor utilizate, numărul si amplasamentul acestora, astfel că va fi obligată fie să elimine cerința criticată, fie să modifice cerința reclamată prin impunerea ca serviciile să fie livrate într-un mediu cloud securizat, conform NIS2 şi Ordinului 489/2009, întrucât achizitoarea a explicat că cerinţa nu vizează un inventar complet, ci garanţia că serviciile sunt livrate într-un mediu cloud securizat, conform NIS2 şi Ordinului 489/2009 așadar accentul trebuie să fie pus pe caracteristicile serviciului (securitate, disponibilitate, certificări). Dacă autoritatea contractantă apreciază că sunt necesare cerințe suplimentare, va completa documentația cu informații concrete justificate pe care să le obțină în vederea obținerii garanției că serviciile sunt livrate într-un mediu cloud securizat. Consiliul obligă autoritatea contractantă să publice în SEAP modificările dispuse în vederea informării tuturor operatorilor economici interesaţi de participarea la procedură, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. 7) Critica formulată de .. SA ( pct. VII din contestație) vizează faptul prin mai multe menţiuni din documentaţia de atribuire nu se asigură o informare completă, corectă şi precisă cu privire la cerinţele achiziţiei şi modul de desfăşurare a procedurii de atribuire, respectiv: - VII.1. Prin documentaţia de atribuire nu este asigurată o informare completă, corectă şi precisă/clară a operatorilor economici privind modalitatea în care va fi acordat punctajul pentru fiecare subfactor; - VII.2. Cu privire la experienţa similară, menţiunile prin care se detaliază modalitatea de îndeplinire nu sunt clare; - VII.3. Integrarea cu sistemul de facturare- Prin raportare la această formulare, vă rugăm să obligaţi Autoritatea contractantă să confirme că integrarea cu sistemul e-Factura se realizează de către ERP-ul existent. Se presupune ca această integrare este deja realizată, întrucât Beneficiarul emite facturi şi în prezent, din sistemul existent de ERP, ci nu din aplicaţia de taxare e-ticketing. - VII.4. Caietul de sarcini nu menţionează în mod clar un număr de SMS- uri de verificare ce trebuie avute în vedere de către toţi ofertanţii pe durata de garanţie a sistemului; - VII.5. Caietul de sarcini nu menţionează toate informaţiile necesare pentru a asigura operatorilor economici o informare completă şi precisă cu privire la precizează cerinţele tehnice pe care trebuie să le respecte Panourile de informare călători. Pagina 84 din 95

Se reține faptul că ulterior luării la cunoștință despre susținerile autorității contractante vizavi de aspectele reclamate, contestatoarea .. SA a precizat prin intermediul concluziilor scrise înregistrate la Consiliu sub nr. 64175/15.09.2025, următoarele: Prin menţiunile din punctul de vedere, apreciem că Autoritatea contractantă a clarificat exclusiv trei aspecte punctuale, subsumate motivului de contestaţie indicat în Secţiunea VII din Contestaţie (privind informarea completă, corectă şi precisă), respectiv: - A clarificat în mod corespunzător criteriul de selecţie privind experienţa similară prevăzut în cadrul Secţiunii III. 1.3 .a) din Fişa de date (Secţiunea VII.2); - A clarificat în mod corespunzător că în cadrul prezentului proiect se doreşte doar integrarea bidirecţională a sistemului de e-ticketing cu aplicaţia de ERP a Beneficiarului pentru transmiterea datelor de vânzare şi management al ofertei tarifare, astfel încât în obiectul contractului nu se încadrează o integrare între sistemul de e-tickting si sistemul RO e-Factura (Secţiunea VII.3); - A clarificat în mod corespunzător cerinţele tehnice referitoare la Panouri de informare a călătorilor (Secţiunea VII.5). În raport de cele mai sus reținute, Consiliul, având în vedere faptul că achizitoarea a achiesat la solicitările .. SA și a adus clarificările solicitate cu privire la modalitatea de îndeplinire pentru experienţa similară (solicitarea de la pct. VII.2), modalitatea de integrare cu sistemul de facturare (solicitarea de la pct. VII.3) și cu privire la completarea informaţiilor necesare pentru a asigura operatorilor economici o informare completă şi precisă cu privire la precizează cerinţele tehnice pe care trebuie să le respecte panourile de informare călători (solicitarea de la pct. VII.5), iar autoarea contestației a comunicat că este de acord cu clarificările/ completările aduse de achizitoare, Consiliul urmează să admită criticile și să oblige autoritatea contractantă să publice în SEAP caietul de sarcini revizuit, în vederea informării tuturor operatorilor economici interesaţi de participarea la procedură, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. În continuare Consiliul va analiza criticile față de care contestatoarea nu a achiesat la argumentele aduse de achiztoare, reclamând în continuare nelegalitatea cerințelor reclamate. Referitor la critica de la pct. VII.1 vizavi de faptul că Prin documentaţia de atribuire nu este asigurată o informare completă, corectă şi precisă/clară a operatorilor economici privind modalitatea în care va fi acordat punctajul pentru fiecare subfactor. Contestatoarea susține în favoarea criticii aduse faptul că în ceea ce priveşte factorul de evaluare "Metodologia de livrare a sistemului", prin documentaţia de atribuire nu este asigurată o informare completă, corectă şi precisă/clară a operatorilor economici privind modalitatea în care va fi acordat punctajul pentru fiecare subfactor., Astfe cu titlu de exemplu, în privinţa primului subfactor, în documentaţia de atribuire nu Pagina 85 din 95

este descris prin raportare la ce repere/criterii obiective şi clare va aprecia comisia de evaluare că ofertantul a furnizat (i) Arhitectură completă, clară, coerent structurată si documentată - 10 pct., (ii) Arhitectura parţial completă, dar insuficient detaliată - 4 pct. (iii) Arhitectura este vagă, lipsesc elemente esenţiale - 0 pct. Astfel contestatoarea concluzionează că pentru a înlătura posibilitatea unor aprecieri subiective şi pentru a asigura transparenţa şi corecta efectuare a evaluării ofertelor prin raportare la criteriile de atribuire achizitoarea trebuie să adopte măsuri de remediere prin care să definească în mod clar criteriile şi modalitatea de analiză pentru acordarea punctajului aferent fiecăruia dintre cele patru criterii care compun factorul Metodologia de livrare a sistemului, prin precizarea baremului de acordare a punctajului în mod transparent și cuantificabil. Se vor reține și precizările achizitoarei în replică la cele reclamate, respectiv rațiunea și justificarea care au stat la baza alegerii subfactorilor și a metodologiei de punctare, respectiv: Scopul evaluării: să distingă metodele care demonstrează fezabilitate, interoperabilitate, securitate şi un calendar realist, în condiţiile unui proiect IT integrat, operat 24/7. Baremele stabilesc repere clare privind rezultatele aşteptate, fără a substitui responsabilitatea ofertantului în elaborarea propriei metodologii. Autoritatea nu defineşte soluţia tehnică în locul operatorului economic, ci indică obiectivele şi criteriile de evaluare care trebuie atinse, lăsând libertatea de a propune abordarea optimă. Subfactor 1 (10 pct.) — Arhitectura sistemului (FIWARE/SynchroniCity sau echivalent) & lista de API- uri Ce se evaluează: coerenţa arhitecturii, decompoziţia pe module, respectarea principiilor de interoperabilitate (context broker, management de evenimente), lista de API-uri expuse/consumate (inclusiv pentru integrări cu ERP/facturare, portal, panouri, validatoare, aplicaţii mobile), strategia de versiuni şi observabilitate. Au fost precizate Capitolul 4 respectiv Capitolul 7 Bareme: • 10 pct. (Complet): arhitectură end-to-end, diagrame şi descrieri detaliate; aliniere explicită la FIWARE/SynchroniCity sau echivalent (ex.: NGSI-LD/Context Broker) + inventar API per componentă (metode, formate, securizare, rate-limit), mapare la Transmodel/NeTEx/SIRI acolo unde e cazul, şi la ITxPT pentru on-board. • 4 pct. (Partial) arhitectură completă sau generalistă, dar cu unele API-uri sumarizate; principiile de interoperabilitate sunt descrise, însă fără mapare exhaustivă la standarde, lipsesc clarificări privind API-urile critice sau conformarea la standarde. • 0 pct.: lipsesc elemente esenţiale; nu se pot deduce integrările. Justificare: susţine interoperabilitatea şi evită vendor lock-in, exact cum recomandă cadrele FIWARE/OASC MIMs şi Interoperable Europe. Având in vedere arhitectura deschisa, modulară, bazată pe standardele FIWARE şi SynchroniCity, care asigură interoperabilitate şi scalabilitate, fiecare componentă e necesar sa fie documentată cu API-uri RESTful, specificând direcţia şi tipul de date schimbate. Standardele FIWARE fiind utilizate pentru context data management (ex: Orion Context Broker), iar SynchroniCity oferind cadrul pentru integrarea urbană şi interoperabilitatea cu alte oraşe inteligente, adoptarea unei arhitecturi deschise şi standardizate garantează un sistem robust, interoperabil şi uşor de extins în viitor. Subfactor 2 (7 pct.) — Strategia .. vs. dezvoltare specifică Ce se evaluează: identificarea clară a componentelor .. (Commercial-Off-The-Shelf) şi a celor custom, argumentarea alegerii (TCO, mentenanţă, actualizări), planul de integrare şi migrare (inclusiv evitarea dublării funcţiilor). Bareme: • 7 pct.: listă ../custom la nivel de modul, criterii de selecţie (performanţă, licenţiere, securitate), plan de migrare şi strategie de actualizare; demonstrarea că .. nu compromite standardele (Transmodel/NeTEx/SIRI, ITxPT). • 3 pct.: listă parţială; criterii sumare; lipsesc unele detalii privind actualizările. • 0 pct.: abordare vagă; risc de sisteme paralele sau lock-in. Pagina 86 din 95

Justificare: optimizează costul total şi acceleră livrarea fără a sacrifica conformitatea la standarde şi integrarea în ecosistem. Identificarea clară a componentelor .. şi a celor dezvoltate la comandă permite o evaluare corectă a gradului de personalizare şi a costurilor implicite. Componentele .. trebuie să fie configurabile şi să ofere mecanisme transparente de expunere a datelor (API-uri, sincronizări), pentru a asigura integrarea cu alte sisteme. Drepturile de utilizare şi proprietate sunt esenţiale pentru sustenabilitatea proiectului. Un echilibru între reutilizarea componentelor .. şi dezvoltarea personalizată optimizează costurile şi asigură controlul Beneficiarului asupra soluţiei livrate. Subfactor 3 (5 pct.) — Arhitectura de securitate (Zero-Trust) & conformare NIS2 Ce se evaluează: controlul accesului (IAM/MFA), segmentarea (micro-segmentare), criptarea, monitorizarea şi răspunsul la incidente, controlul furnizorilor (lanţ de aprovizionare), logging/audit, BCP/DR şi RTO/RPO; coerenţă cu RACI. Bareme: • 5 pct.: arhitectură Zero-Trust, politici IAM/MFA, criptare end-to-end, plan de răspuns la incidente aliniat OUG 155/2024 (NIS2), logare/audit, BCP/DR cu RTO/RPO măsurabile, responsabilităţi RACI pe fiecare control. • 3 pct.: elemente principale prezente, dar fără metrifici sau fără mapare completă la RACI/NIS2. • 0 pct.: măsuri generale; lipsesc proceduri operaţionale. Justificare: minimizarea expunerii şi asigurarea rezilienţei pentru un sistem cu impact public. Implementarea unei arhitecturi de securitate bazate pe principiul Zero Trust minimizează riscurile de acces neautorizat şi atacuri cibernetice. Conformitatea cu directiva NIS2 este esenţială pentru protejarea infrastructurilor critice. Mecanismele de autentificare, criptare, audit şi backup trebuie să fie integrate nativ în sistem. O arhitectură de securitate solidă şi conformă cu NIS2 oferă încredere, protecţie şi rezilienţă cibernetică pe termen lung. Subfactor 4 (3 pct.) — Planul de implementare şi calendarul Ce se evaluează: WBS, dependenţe, criterii de acceptanţă, testare/UAT, cut-over şi hiper-care. Bareme: • 3 pct.: plan granular (milestone-uri, livrabile, resurse), criterii de acceptanţă pe livrabile, strategie UAT şi plan de tranziţie în producţie (cut-over) + hiper-care. • 2 pct.: plan general; lipsesc criterii de acceptanţă/hiper-care. • 0 pct.: calendar lipsă sau necorelat cu resursele. Justificare: reducerea riscurilor de derapaj şi neconformitate la recepţie (art. 83 - informare completă). Ulterior luării la cunoștință despre precizările achizitoarei, contestatoarea a susținut următoarele: Prin Punctul de vedere transmis, apreciem că Autoritatea contractantă a completat şi a definit în mod clar criteriile şi modalitatea de analiză pentru acordarea punctajului în ceea ce priveşte primul şi al treilea criteriu, respectiv pentru: - Subfactor 1: Arhitectura sistemului construita in jurul standardelor FIWARE si SynchroniCity cu o lista de API-uri pentru fiecare componenta din sectiunea de Arhitectura din anexa 3 la caietul de sarcini (10 puncte); - Subfactor 3: Arhitectura de securitate (Zero Trust + NIS2) (5 puncte); În ceea ce priveşte Subfactorul 2 - Strategia .. vs dezvoltare specifică, vă rugăm să constataţi că în continuare nu este asigurată o informare completă, corectă şi precisă/clară a operatorilor economici privind modalitatea în care va fi acordat punctajul pentru acest subfactor, Autoritatea Contractantă limitându-se a relua menţiunile din caietul de sarcini. (...) În concret, autoritatea nu precizează criteriile în funcţie de care se punctează raportul dintre .. şi dezvoltare specifică. Nu este specificat în mod clar dacă se punctează mai bine un număr mai mare de componente .. sau o selecţie mai restrânsă, dar mai relevantă. În lipsa unei grile de evaluare cuantificabile, compararea ofertelor este imposibil de realizat în mod obiectiv, iar rezultatul evaluării rămâne la latitudinea exclusivă a evaluatorilor. (...) În ceea ce priveşte Subfactorul 4 - Planul de implementare şi calendarul, informarea operatorilor economici rămâne neclară şi incompletă, întrucât descrierea modalităţii de acordare a punctajului este neclară şi, în acest caz, nu permite verificarea concretă a Pagina 87 din 95

informaţiilor furnizate de către ofertanţi şi conferă Autorităţii contractante o libertate de apreciere nelimitată cu ocazia evaluării. În concret, în barem sunt introduşi termeni precum „UAT" şi „hiper-care", care nu se regăsesc în caietul de sarcini (CS) şi pentru care nu sunt puse la dispoziţie definiţii, şabloane sau cerinţe minime care să sprijine elaborarea documentaţiei de ofertă. De asemenea, nu sunt definiţi parametri concreţi ai „granularităţii" pentru evaluarea planului de implementare şi a calendarului, astfel încât aceeaşi ofertă ar putea fi încadrată la 2 puncte sau la 3 puncte în funcţie de o apreciere subiectivă şi netransparentă a evaluatorului. Suplimentar, nu este clar dacă se impune un anumit nivel WBS, un număr minim de jaloane ori o unitate de timp care să facă diferenţa între punctaje. Cu ocazia formulării concluziilor scrise autoritatea contractantă a precizat următoarele: Critica privind subfactorul 2 este nefondată. Autoritatea contractanta solicită o delimitare clară între componentele .. şi cele dezvoltate la comandă, pentru a evalua gradul de personalizare, interoperabilitate, licentiere post-contract, mentenanta post-contract şi sustenabilitate. Cerinţa este justificată tehnic şi formulată clar. Afirmaţia că delimitările .. vs. custom sunt neevaluabile ignoră faptul că autoritatea contractanta solicită explicit descrierea componentelor, drepturile de utilizare şi capacitatea de integrare. Aceste elemente permit o evaluare obiectivă a strategiei propuse de ofertanţi. Critica privind libertatea excesivă a evaluatorilor este nefondată. Documentaţia delimitează clar subfactorii şi punctajele, iar cerinţele de detaliere (ex. API-uri, granularitate, criterii de acceptanţă) permit o analiză comparabilă şi verificabilă. Afirmaţia că lipsesc criteriile de punctare este contrazisă de cerinţele din caietul de sarcini. Autoritatea contractanta solicită descrierea arhitecturii, a componentelor, a planului de implementare şi a criteriilor de acceptanţă, ceea ce permite o evaluare fundamentată. Documentaţia respectă prevederile art. 154 şi 189 din Legea 98/2016. Factorii de evaluare sunt delimitaţi, punctajele sunt precizate, iar cerinţele permit verificarea efectivă a informaţiilor furnizate de ofertanţi. Critica privind subfactorul 4 este nefondată. Autoritatea contractanta solicită un plan detaliat de implementare, cu jaloane, criterii de acceptanţă şi termeni standard (UAT, cut- over/lansare in productie, hiper-care/mentenanta imediata), ceea ce permite o evaluare obiectivă a fezabilităţii ofertei. Termenii UAT şi hiper-care (hypercare) sunt standard în proiectele IT. Documentaţia le utilizează corect, iar evaluarea se face pe baza granularităţii planului şi a criteriilor de acceptanţă, nu pe interpretări subiective. Afirmaţia că lipsesc formatele pentru criterii de acceptanţă este nefondată. Autoritatea contractanta solicită definirea jaloanelor şi a criteriilor de acceptanţă pe livrabile, ceea ce permite o evaluare comparabilă între oferte. Critica privind hiper-care fără parametri este contrazisă de practica standard. Hiper- care este o etapă de suport post-implementare, iar cerinţele autoritatii contractante privind disponibilitatea, suportul şi monitorizarea sunt suficiente pentru evaluare. Raționamentul conturat de autoritatea contractantă în favoarea faptului că Factorii de evaluare utilizaţi de autoritatea contractanta sunt formulaţi cu punctaje maxime pe subfactori, ceea ce delimitează strict aria de analiză şi exclude subiectivismul. În plus, prin cerinţele detaliate (arhitectură, API-uri, securitate NIS2, granularitatea planului), comparabilitatea şi verificabilitatea ofertelor sunt garantate este judicios și va fi reținut de Consiliu în soluționare din considerentele mai jos expuse. Așa cum a susținut achizitoarea și cum este precizat în cadrul strategiei de contractare rațiunea care a stat la baza alegerii subfactorilor și a metodologiei de punctare pentru factorul de evalure reclamat, Metodologia de livrare a sistemului este Scopul evaluării: să distingă metodele care demonstrează fezabilitate, interoperabilitate, securitate şi un calendar realist, în condiţiile unui proiect IT integrat, operat 24/7. Baremele stabilesc repere clare privind Pagina 88 din 95

rezultatele aşteptate, fără a substitui responsabilitatea ofertantului în elaborarea propriei metodologii. Autoritatea nu defineşte soluţia tehnică în locul operatorului economic, ci indică obiectivele şi criteriile de evaluare care trebuie atinse, lăsând libertatea de a propune abordarea optimă. Subfactorii de evaluare 2 și 4 reclamați se regăsesc astfel precizați în cuprinsul caietului de sarcini, la secțiunea 14 Factori de evaluare: 2. METODOLOGIA DE LIVRARE A SISTEMULUI 25% 25 puncte Descriere: Se evaluează claritatea şi deschiderea arhitecturii propuse, integrarea standardelor relevante, diferenţierea între componentele reutilizabile şi cele dezvoltate la comandă, nivelul de securitate conform cerinţelor actuale, precum şi coerenţa planului de implementare şi livrare. 2.2. Componente .. (Commercial Off-The-Shelf) vs dezvoltate pentru PMT- 7 % - 7 puncte Se va evalua: •Evidențierea componentelor .. față de cele dezvoltate la comandă. •Modul în care componentele .. expun datele către terți (ex: API-uri, fișiere, sincronizări). •Nivelul de configurabilitate/adaptabilitate al componentelor .. reutilizate. De menționat ca PMT va avea drept de folosință fără costuri extra pe intreaga perioada de garanție a proiectului, iar componentele custom vor intra in proprietatea PMT. Justificare factor de evaluare: Identificarea clară a componentelor .. și a celor dezvoltate la comandă permite o evaluare corectă agradului de personalizare și a costurilor implicite. Componentele .. trebuie să fie configurabile și să ofere mecanisme transparente de expunere a datelor (API-uri, sincronizări), pentru a asigura integrarea cu alte sisteme. Drepturile de utilizare și proprietate sunt esențiale pentru sustenabilitatea proiectului. Un echilibru între reutilizarea componentelor .. și dezvoltarea personalizată optimizează costurile și asigură controlul Beneficiarului asupra soluției livrate. Algoritm de acordare a punctajului:

• Listă completă .. vs custom + metode de expunere a datelor explicite. Toate componentele vor fi clar clasificate in .. sau custom, conform cap. 2.1 Obiectivul Achizitiei, 4.1 Definiții, principii și constrângeripentru arhitectura sistemului - 7 puncte •Listă generică .. vs custom + metode de expunere a datelor parțiale. Unele informații sunt generice si neclare conform, cap. 2.1 Obiectivul Achizitiei, 4.1 Definiții, principii și constrângeri pentru arhitectura sistemului- 3 puncte

• Lipsă detalii sau incoerență în listă Există informații lipsă, conform cap. 2.1Obiectivul Achizitiei, 4.1 Definiții, principii și constrângeri pentru arhitectura sistemului- 0 puncte 2.4. Plan de implementare și termene Se va evalua: •Coerența și realismul planului de implementare propus pentru sistemul e-ticketing.

• Corelarea etapelor cu activitățile descrise în caietul de sarcini (analiză, livrare, integrare, testare, punere în funcțiune, instruire, suport). •Gradul de detaliere al livrabilelor, termenelor, resurselor și dependențelor. •Existența unui grafic Gantt sau echivalent, cu milestone-uri clare. Justificare factor de evaluare: Un plan de implementare coerent, corelat cu activitățile din caietul de sarcini și susținut de un grafic Gantt detaliat, reflectă capacitatea ofertantului de a livra sistemul în termenele asumate. Detalierea resurselor, livrabilelor și dependențelor permite o gestionare eficientă a proiectului și reducerea riscurilor. Un plan realist și bine structurat este cheia unei implementări eficiente și a unei colaborări transparente cu Beneficiarul.- 3% - 3 puncte

• Planul de implementare complet Planul de implementare este structurat pe etape SDLC (ex: analiză, design, dezvoltare, testare,migrare, training, rollout); Planul de implementare include: •Grafic detaliat (Gantt sau echivalent); •Pentru fiecare etapă: livrabile clare, durată, responsabilități; •Interdependențe logice între etape; Termenele sunt: •Realist estimate în raport cu complexitatea livrabilelor; •Adaptate la calendarul proiectului (ex: termen limită 31.12.2026); •Se prevede o fază de pilotare/testare și una de scalare treptată (go-live gradual); Este integrat un plan de tranziție dinspre sistemele actuale, fără discontinuitate în servicii; Se menționează o echipă de livrare și roluri asociate. Conform Cap. 4.2.4.3 Graficul de livrare, Cap. 10, Livrabile hardware, Anexa 2 punctul G, 3 puncte Pagina 89 din 95

• Planul de implementare este parțial complet Planul prezintă o structură generală, dar unele etape nu sunt detaliate iar livrabilele sunt vagi- 2 puncte Termenele sunt sumar indicate, dar fără repere precise; Lipsesc corelări între resurse și activități. Graficul este lipsă sau superficial (ex: doar o listă cronologică simplă). Conform Cap. 4.2.4.3 Graficul de livrare, Cap. 10, Livrabile hardware, Anexa 2 punctul G, •Planul de implementare este neclar si incomplete- 0 puncte Planul lipsește sau constă doar într-o înșiruire informală (ex: „vom livra în etape”).Nu există termene, livrabile sau alocare de resurse. Nu există structură de etapizare sau corelare logică între activități. Nu sunt prevăzute activități de testare, tranziție, migrare, training sau recepție. Conform Cap. 4.2.4.3 Graficul de livrare, Cap. 10, Livrabile hardware, Anexa 2 punctul G. Față de cele redate Consiliul determină că autoritatea contractanta a publicat bareme cuantificabile prin alocarea punctajelor pe subfactori şi prin cerinţele de detaliere. Sunt precizate bareme cuantificabile prin alocarea punctajelor pe subfactori şi prin cerinţele de detaliere. Evaluarea se face pe baza gradului de concretizare, granularitate şi capacitate de integrare, ceea ce asigură transparenţă. Punctajele sunt alocate explicit pe subfactori, iar cerinţele de detaliere permit o evaluare obiectivă în funcţie de gradul de concretizare a propunerii tehnice. Consiliul achiesează la susținerile achizitoarei care a explicat punctual • Pentru subfactorii 2 şi 4, autoritatea contractanta subliniază că cerinţele nu lasă libertate „nelimitată", ci permit o evaluare obiectivă pe baza gradului de concretizare şi detaliere a propunerii tehnice. 2. Subfactor 2 - .. vs. dezvoltare specifică • Justificarea acestui subfactor, inclusă chiar în caietul de sarcini, este că identificarea clară a componentelor .. şi a celor dezvoltate la comandă permite o evaluare corectă a gradului de personalizare şi a costurilor implicite. • Componentele .. trebuie să fie nu doar livrate „ca atare", ci să fie configurabile, documentate şi să expună date prin API-uri şi mecanisme de sincronizare transparente, pentru a asigura integrarea cu alte sisteme. În lipsa acestor cerinţe, autoritatea contractanta ar risca să achiziţioneze soluţii închise, dificil sau imposibil de integrat ulterior. • Totodată, caietul de sarcini precizează că drepturile de utilizare şi proprietate sunt esenţiale pentru sustenabilitatea proiectului. Evaluarea strategiei propuse de ofertanţi cu privire la raportul dintre .. şi dezvoltare custom asigură că soluţia finală nu va genera dependenţă excesivă de un anumit furnizor şi că va putea fi menţinută şi dezvoltată în timp.  • Prin urmare, acest subfactor nu este neclar şi nici subiectiv, ci urmăreşte exact comparabilitatea ofertelor şi alegerea unei soluţii sustenabile şi eficiente pe termen lung. 3. Subfactor 4 - Plan de implementare şi calendar • Solicitarea unui plan detaliat nu este o formalitate, ci un instrument pentru a evalua realismul şi fezabilitatea ofertei. • Termenii utilizaţi sunt standard în proiectele IT: o UAT (User Acceptance Testing) = testarea de acceptanţă a sistemului de către utilizatorii desemnaţi înainte de punerea în producţie; o Cut-over (go-live, lansare in productie) = momentul de tranziţie efectivă la noul sistem, cu migrarea datelor şi pornirea producţiei; o Hiper-care (mentenanta imediata) = perioada imediat următoare cut-over-ului, în care furnizorul oferă suport intensiv pentru stabilizarea solutiei, monitorizarea performantei si rezolvarea rapida a incidentelor • Evaluarea se va face pe baza granularităţii planului (nivel de detaliu, definirea jaloanelor, criterii de acceptanţă pe livrabile), ceea ce permite o comparaţie obiectivă între oferte. Constatându-se fapul că documentaţia respectă prevederile art. 154 şi 189 din Legea 98/2016, respectiv factorii de evaluare sunt delimitaţi, punctajele sunt precizate, iar cerinţele permit verificarea Pagina 90 din 95

efectivă a informaţiilor furnizate de ofertanţi, astfel că în cazul celor doi subfactori reclamați achizitoarea a precizat bareme cuantificabile prin alocarea punctajelor prin cerinţele de detaliere. Contrar celor susținute de contestatoare, precum că libertatea excesivă a evaluatorilor documentaţia delimitează clar subfactorii şi punctajele, iar cerinţele de detaliere (ex. API-uri, granularitate, criterii de acceptanţă) permit o analiză comparabilă şi verificabilă. În mod similar aceeași concluzie de netemeinicie va fi reținută de Consiliu și vizavi de pretinsa lipsă a criteriile de punctare este contrazisă de cerinţele din caietul de sarcini, așa cum a fost anterior reținut, autoritatea contractanta solicită descrierea arhitecturii, a componentelor, a planului de implementare şi a criteriilor de acceptanţă, ceea ce permite o evaluare fundamentată. Câtă vreme documentaţia defineşte clar fiecare subfactor, alocă punctaje şi stabileşte cerinţe tehnice care permit o evaluare obiectivă şi comparabilă, contrar celor susținute de contestatoare solicitarea de eliminare a subfactorilor este nejustificată În raport de cele mai sus reținute, Consiliul constată că societatea contestatoare nu a dovedit că este vătămată de prevederile documentației de atribuire, aspectele reclamate vizavi de factorii de evaluare reclamați nefiind de natură să o prejudicieze. În raport de cele anterior reținute se constată caracterul nefondat al criticii aduse vizavi de pretinsa nelegalitate a algoritmului de punctare aferent factorului de evaluare Metodologia de livrare a sistemului. Referitor la critica de la pct. VII.4 vizavi de faptul că Caietul de sarcini nu menţionează în mod clar un număr de SMS-uri de verificare ce trebuie avute în vedere de către toţi ofertanţii pe durata de garanţie a sistemului, contestatoarea a reclamat că în cadrul Subsecţiunii 5.4.5.2 din Caietul de sarcini - Sistemul de Gateway SMS pentru toate tranzacţiile care necesita 2FA/MFA se menţionează că: Pentru toate tranzacţiile care necesita 2FA/MFA, se va utiliza un Gateway SMS. Acesta va fi inclus in preţul ofertei pentru toata perioada de garanţie. De pe el se vor transmite SMS- uri de verificare 2FA/MFA. Gateway-ul va fi de tip PERSONALIZAT si dedicat (nu va fi shared cu alte firme/aplicaţii). Toate costurile ocazionate de folosirea lui, vor fi achitate de către ofertant. Nu se accepta costuri suplimentare generate de depăşirea numărului de sms-uri din oferta. Prin această cerinţă se solicită includerea în ofertă a unor costuri ce nu pot fi cuantificate, întrucât nu este menţionată o limită maximă privind numărul de SMS-uri de verificare ce trebuie avute in vedere de către toti ofertanţii pe durata de garanţie a sistemului. Astfel, contestatoarea apreciază că nu sunt menţionate toate informaţiile necesare pentru a asigura operatorilor economici o informare completă, corectă şi precisă cu privire la cerinţele achiziţiei. În consecinţă, contestatoarea solicită obligarea achizitoarei să precizeze în mod clar în cadrul caietului de sarcini un număr de SMS-uri de verificare ce trebuie avute în vedere de către toţi ofertanţii pe durata de garanţie a sistemului. Pagina 91 din 95

Se vor reține și precizările achizitoarei aduse în replică la cele reclamate respectiv faptul că volumul de SMS depinde de scenariile stabilite (MFA/OTP, alerte), de adopţia utilizatorilor şi de politicile de securitate. De aceea, documentaţia prevede „Inception Report" şi „Analiză-Proiectare" pentru a dimensiona fundamentat (ipoteze de trafic, profiluri, mix tehnic SMS/Push/TOTP), a optimiza costurile şi a valida metode alternative de autentificare. Solicitarea acestor livrabile este proporţională cu complexitatea proiectului şi asigură comparabilitatea ofertelor. Mai multe detalii s-au prezentat la punctul III.1. Cu privire la Subsecţiunea 4.2.7.1 - „Inception Report" si „Analiză - Proiectare" Ulterior luării la cunoștință despre precizările achizitoarei, contestatoarea a susținut că 126. Cu toate că volumul de SMS depinde, într-adevăr de scenariile stabilite şi de adopţia utilizatorilor, documentaţia de atribuire precizează (în Caietul de sarcini - Secţiunea 2.5 „Situaţia actuală", Subsecţiunea 2.5.2 „Sistemul actual de taxare") că Autoritatea contractantă are deja implementat un sistem modern de plată prin SMS. Prin urmare, .. deţine date istorice privind volumul de plăţi prin SMS, astfel încât poate pune la dispoziţia ofertanţilor informaţii concrete privind traficul SMS din sistemul existent. 127. Lipsa unei dimensionări minime a cerinţelor în documentaţia de atribuire contravine în mod direct obligaţiei Autorităţii contractante de a furniza operatorilor economici informaţiile necesare pentru fundamentarea ofertelor. În absenţa unor date obiective, precum volumele istorice de trafic SMS din sistemul actual, ofertanţii sunt constrânşi să îşi fundamenteze propunerile exclusiv pe ipoteze, ceea ce generează un risc major de supraestimare sau subestimare a costurilor şi, în consecinţă, de lipsă de comparabilitate între oferte. 128. Această deficienţă reprezintă o încălcare a dispoziţiilor art. 154 alin. (1) din Legea nr. 98/2016, care impune Autorităţii contractante obligaţia de a elabora documentaţia de atribuire astfel încât aceasta să conţină toate informaţiile necesare pentru asigurarea unei informări complete, corecte şi precise a operatorilor economici cu privire la cerinţele achiziţiei, obiectul contractului şi modul de desfăşurare a procedurii. În acelaşi sens, art. 20 alin. (2) din HG nr. 395/2016 prevede că documentaţia de atribuire trebuie să includă orice cerinţă, criteriu, regulă şi alte informaţii necesare pentru a asigura ofertanţilor o informare completă, corectă şi explicită. 129. În aceste condiţii, solicităm ca Autoritatea contractantă care are la dispozitie volumele istorice de trafic SMS din sistemul actual să precizeze numărul estimativ de SMS- uri, pentru a permite o dimensionare fundamentată a cerinţelor şi a costurilor aferente. Deşi optimizarea şi calibrarea mixului tehnic (SMS/Push/TOTP) pot fi realizate ulterior, în faza de analiză- proiectare, dimensionarea orientativă trebuie să se bazeze pe datele deja existente, pentru a asigura respectarea principiilor legalităţii, transparenţei şi tratamentului egal al operatorilor economici. Cu ocazia formulării concluziilor scrise autoritatea contractantă a precizat următoarele: Critica privind lipsa unei limite maxime de SMS-uri ignoră faptul că volumul real depinde de adopţia utilizatorilor şi de mixul tehnic ales (SMS/Push/TOTP). Documentaţia prevede livrabile precum Inception Report şi Analiză-proiectare tocmai pentru a fundamenta aceste scenarii. Autoritatea contractanta : dimensionare prin rapoarte Autoritatea contractanta a precizat că dimensionarea se va face prin livrabilele tehnice obligatorii, care vor include ipoteze de trafic, profiluri de utilizatori şi scenarii de autentificare. Această abordare permite o estimare realistă şi adaptată la nevoile reale ale sistemului. .. dispune de date istorice privind utilizarea plăţilor prin SMS în sistemul actual. Acestea pot fi utilizate ca referinţă pentru estimarea volumului de SMS-uri necesare în noul sistem, contribuind la transparenţă şi fundamentarea ofertelor.  Afirmaţia că lipsa datelor încalcă informarea este nefondată. Autoritatea contractanta este dispusă să publice, prin clarificare, un număr orientativ de SMS-uri pe baza volumelor istorice, oferind astfel o referinţă utilă fără a impune un plafon fix. Pagina 92 din 95

Obligaţia de furnizare a informaţiilor este respectată prin angajamentul autoritatea contractanta de a publica date istorice prin clarificare pe SEAP şi de a solicita livrabile tehnice care vor fundamenta scenariile de trafic. Această abordare asigură transparenţă şi tratament egal. Autoritatea contractanta va comunica un volum estimativ de SMS-uri, bazat pe datele istorice disponibile, exclusiv ca referinţă pentru toti ofertanţii prin clarificare pe SEAP. Această măsură sprijină fundamentarea ofertelor fără a impune constrângeri artificiale sau plafonări nejustificate. Concluzie pentru Subcapitolul II.7.2 Numărul de SMS-uri pentru 2FA/MFA 1. Rolul SMS-urilor în proiect • Cerinţa de includere a unui Gateway SMS dedicat pentru toate tranzacţiile ce necesită autentificare multifactor (2FA/MFA) este proporţională şi direct legată de obiectul contractului, având rolul de a asigura securitatea tranzacţiilor digitale ale cetăţenilor. • Nu este o funcţionalitate suplimentară sau „în afara obiectului", ci o componentă centrală de securitate în acord cu NIS2 şi cu bunele practici în e-ticketing. 2. De ce nu a fost precizat un volum fix • Volumul real de SMS-uri depinde de factori multipli: adopţia utilizatorilor, mixul tehnic ales (SMS/Push/TOTP), politica de securitate stabilită împreună cu autoritatea contractanta în etapa de analiză-proiectare. • De aceea, documentaţia a prevăzut Inception Report şi Analiză-proiectare ca livrabile obligatorii, tocmai pentru a fundamenta pe baze reale scenariile de trafic şi costurile asociate. 3. Date istorice şi transparenţă • .. are într-adevăr un istoric de utilizare a plăţilor prin SMS în sistemul actual de ticketing. Aceste date pot fi folosite pentru orientare. • Autoritatea contractanta este dispusă să publice, prin clarificare, un număr orientativ de SMS-uri pe baza volumelor istorice (ex. câteva sute de mii pe an), exclusiv ca referinţă pentru ofertanţi, fără a constitui un plafon sau o obligaţie fixă. • Autoritatea contractanta este dispusă să publice, prin clarificare, sa impuna un numar minim de SMS-uri pe baza acelorasi date de consum. Consiliul, având în vedere faptul că achizitoarea a achiesat la solicitările .. SA potrivit cărora Autoritatea contractantă care are la dispozitie volumele istorice de trafic SMS din sistemul actual să precizeze numărul estimativ de SMS- uri, pentru a permite o dimensionare fundamentată a cerinţelor şi a costurilor aferente, față de explicațiile aduse de achizitoare, Consiliul urmează să admită criticile și să oblige autoritatea contractantă să publice în SEAP clarificările/precizările aduse pe calea punctului de vedere formulat în vederea informării tuturor operatorilor economici interesaţi de participarea la procedură, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. Luând în considerare ansamblul considerentelor expuse, Consiliul are în vedere că, dată fiind complexitatea contractului de furnizare (care cuprinde și prestarea de servicii aferente), importanța acestuia, durata contractuală și rezultate așteptate de la derularea proiectului, asigurarea posibilității depunerii unor oferte conforme, autoritatea contractantă a depus diligențele necesare întocmirii unei documentații care să țină seama de toate aspectele pe care le implică contractul de furnizare, luând în considerare specificul acestuia, ce implica o atenție sporită din partea autorității contractante astfel încât să poată fi asigurată derularea proiectului. Pagina 93 din 95

Așa cum a fost mai sus reținut, achizitoarea a subliniat că prioritar a fost interesul public unde așteptările și nevoile actuale și imediate de a dezvolta și moderniza transportul public de călători sunt foarte mari, oportunitatea de a a materializa acest deziderat reprezintă un obiectiv major al Municipiului Timișoara. Astfel, în privința criticilor nr. IV, V, VI, VII.2, VII.3, VII.4 și VII 5 din cuprinsul contestației, se impune remedierea documentației de atribuire potrivit considerentelor reținute în motivare. Obligă autoritatea contractantă, în termen de 20 zile de la data primirii

prezentei

decizii,

să

modifice/completeze/remedieze documentația de atribuire, conform celor reținute în considerente, și să aducă la cunoștința tuturor operatorilor economici interesați măsurile adoptate, prin postarea acestora în SEAP, cu stabilirea unei noi date de depunere a ofertelor, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. Pentru considerentele evocate în motivarea prezentei, respinge, ca nefondate, restul solicitărilor din cadrul celorlalte critici din contestația formulată de .. SA, în contradictoriu cu ... Pentru aceste motive, în baza legii și a mijloacelor de probă aflate la dosar, CONSILIUL DECIDE: În temeiul art. 26 alin. (2) și (5) 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, pentru considerentele evocate în motivarea prezentei, admite, în parte, contestația formulată de .. SA, în contradictoriu cu MUNICIPIUL, în privința criticilor nr. IV, V, VI, VII.2, VII.3, VII.4 și VII 5 din cuprinsul contestației. Obligă autoritatea contractantă, în termen de 20 zile de la data primirii

prezentei

decizii,

să

modifice/completeze/remedieze documentația de atribuire, conform celor reținute în considerente, și să aducă la cunoștința tuturor operatorilor economici interesați măsurile adoptate, prin postarea acestora în SEAP, cu stabilirea unei noi date de depunere a ofertelor, potrivit dispozițiilor art. 55 alin. (1) din H.G. nr. 395/2016. Totodată, în măsura în care informațiile referitoare la elementele pentru care Consiliul a dispus remedierile mai sus amintite, se regăsesc și în cadrul altor documente din conținutul documentației de autoritatea contractantă va proceda în consecință și va corela informațiile în concordanță cu remedierile dispuse. Pagina 94 din 95

În temeiul art. 26 alin. (6) din Legea nr. 101/2016 pentru considerentele evocate în motivarea prezentei, respinge, ca nefondate restul solicitărilor din cadrul celorlalte critici din contestația formulată de .. SA, în contradictoriu cu ... Prezenta decizie este obligatorie pentru părțile cauzei potrivit dispozițiilor art. 28 alin. (1) din Legea nr. 101/2016, cu modificările și completările ulterioare. Împotriva prezentei decizii se poate formula plângere, în termen de 10 zile de la comunicare pentru părțile cauzei, respectiv de la data luării la cunoștință de către alte persoane vătămate, în temeiul art. 29 din Legea nr. 101/2016. PREȘEDINTE, MEMBRU, MEMBRU,

Redactată în 4 exemplare originale, conține 85 pagini. Pagina 95 din 95