Servicii în vederea dezvoltării sistemului informațional „Registrul drumurilor publice”

Din punct de vedere tehnic, obligația Prestatorului este de a expune datele/serviciile geospațiale prin standarde deschise — OGC WMS/WFS/WMTS și/sau OGC API Features/Tiles (NFRQ05) — și API-uri documentate (NFRQ01/pct. 5 Livrabile), astfel încât acestea să poată fi consumate de Portalul EVO. Caietul nu fixează mecanismul tehnic exact (componentă nativă/iframe/API/redirecționare) — stabilește doar principiul de mai sus. Mecanismul concret va fi stabilit în etapa de proiectare tehnică, prin coordonare cu deținătorul/administratorul Portalului EVO. Domeniul de intervenție al proiectului (pct. 3 din caiet) definește obiectul contractului exclusiv ca dezvoltarea SI RDP; nu include dezvoltări sau ajustări ale Portalului EVO. Eventuale adaptări necesare pe partea EVO nu fac parte din obligațiile Prestatorului SI RDP și cad, după caz, în sarcina deținătorului platformei (AGE). Da — integrarea se realizează exclusiv prin mecanismele oficial suportate de platforma EVO, fără ca Prestatorul să aibă acces la codul sursă al platformei EVO sau să îl modifice.

Caietul de sarcini nu specifică exhaustiv formatul exact al datelor deținute actual de MIDR/AND/APL (nu confirmă și nu exclude Excel, baze relaționale, CAD/Shapefile). Este confirmată doar existența sistemelor moștenite ТРАССА / Дорога-2011 / Титул-2005 (pct. 8.1, FRQ034), pentru care se precizează explicit că „specificațiile tehnice privind structura și formatul exact al datelor compatibile vor fi puse la dispoziția Consultantului după semnarea contractului." Sursa exactă și formatul definitiv al datelor vor fi stabilite de comun acord cu Beneficiarul în etapa de analiză și elaborare a metodologiei de migrare (NFRQ62-63). Schemă de date unificată: Caietul definește un model funcțional de date (câmpuri, tipuri, validări) prin Formularele din Anexele 2–22, dar nu o schemă DDL completă — elaborarea modelului de date detaliat (DDL, relații, indexări) este obligația Consultantului (NFRQ10). Cerința de bază obligatorie: bază de date tranzacțională cu extensie geospațială de tip PostGIS sau echivalent, indecși GiST/SP-GiST, SRID consistent (NFRQ04); servire prin standarde OGC WMS/WFS/WMTS/OGC API cu vector tiles și cache (NFRQ05, NFRQ06). Caietul nu tranșează dacă e nevoie de un GIS Server dedicat separat sau dacă randarea direct din PostGIS e suficientă — aceasta este o decizie arhitecturală care aparține Consultantului, cu condiția respectării țintelor de performanță din NFRQ18 (tile p95 ≤ 300ms, interogări spațiale ≤ 2s pentru seturi până la 100k geometrii). GIS Server: Componenta de tip GIS Server necesară publicării și servirii straturilor cartografice (conform standardelor OGC prevăzute la NFRQ05 — WMS/WFS/WMTS și/sau OGC API Features/Tiles) este în sarcina Operatorului Economic, care o va proiecta, instala, configura și menține în infrastructura MCloud alocată proiectului, containerizată conform NFRQ07. Soluția nu include achiziția de componente hardware (NFRQ03). La momentul actual, Autoritatea Contractantă nu deține confirmarea existenței unei instanțe GIS Server partajate existenței unei instanțe GIS Server partajate, deja disponibilă în infrastructura MCloud, pe care sistemul SI RDP ar putea-o consuma direct. În lipsa unei asemenea confirmări, Operatorul Economic va proiecta soluția pornind de la premisa că trebuie să asigure integral componenta GIS Server ca parte a livrabilelor sale. În cazul în care, ulterior, se confirmă — prin coordonare cu STISC, administratorul platformei MCloud — disponibilitatea unui serviciu GIS partajat la nivel guvernamental, utilizarea acestuia va fi analizată și, după caz, agreată împreună cu Beneficiarul, fără ca aceasta să constituie automat o obligație de restructurare a componentei deja proiectate/implementate de Operatorul Economic. Componentele GIS propuse (ex. GeoServer, MapServer sau echivalent) trebuie să respecte principiul independenței față de furnizor și cerințele de licențiere aplicabile sistemelor informaționale de stat.

Da, cu o excepție. Conform pct. 7.8.2, pentru 8 din cei 9 experți cheie, caietul folosește formularea „Deținerea unei certificări..." alături de studii și experiență — este deci o cerință minimă de calificare, la fel ca studiile și experiența. Excepție: pentru expertul UI/UX Designer, caietul precizează expres că certificarea/portofoliul „va constitui un avantaj" — deci nu este eliminatorie pentru acest rol. La 5 din cei 8 experți cu certificare obligatorie, denumirile concrete indicate (PMI/IPMA/PRINCE2, PMI-PBA/IIBA, TOGAF, Oracle Certified Professional/Azure DB Administrator/PostgreSQL Professional, ISTQB) sunt precedate de abrevierea „ex." — adică sunt exemple ale unei categorii acceptate, nu o listă exhaustivă/închisă. Prin urmare, se acceptă orice certificare echivalentă din același domeniu profesional (management de proiect / analiză de business / arhitectură software / baze de date / testare), chiar dacă nu poartă exact denumirea exemplificată — cu condiția să fie o certificare reală, recunoscută, relevantă pentru rolul respectiv. La experții FrontEnd, BackEnd și DevOps, caietul e deja formulat generic („certificare... în una din tehnologiile solicitate"), fără nicio denumire fixă — deci flexibilitate maximă acolo. Autoritatea contractantă nu acceptă substituirea integrală a certificării formale prin experiență practică echivalentă. Cerințele de certificare menționate la pct. 7.8.2 rămân cerințe minime obligatorii de calificare pentru cei 8 experți cheie vizați, cumulative față de studii și experiența profesională, nu alternative la acestea. Poziția este valabilă și opozabilă tuturor operatorilor economici participanți la procedură.

Autoritățile Publice Locale sunt incluse în domeniul de utilizare al SI RDP — conform pct. 4 (Principalii factori interesați), APL vor putea consulta și completa date privind drumurile locale aflate în gestiunea lor, iar rolul „Registrator local" este definit generic pentru reprezentanții APL de nivelul II. Termenul general de dezvoltare și implementare este de 11 luni calendaristice de la semnarea contractului (pct. 6). Caietul de sarcini nu stabilește repartizarea exactă a duratei pe etape — aceasta revine explicit Consultantului: „La etapa de achiziție, Consultantul este obligat să prezinte în propunerea tehnică un plan detaliat al etapelor de implementare, cu indicarea termenelor de execuție pentru fiecare etapă. Aceste termene vor constitui criteriu de eligibilitate și vor sta la baza monitorizării progresului." Metodologia de livrare este agilă/iterativă (pct. 7.1, 7.4), cu funcționalități prioritizate în backlog de către Beneficiar. Nu există un calendar prestabilit de onboarding al APL în caietul de sarcini la această etapă. Conform pct. 6, ofertantul este obligat să prezinte în propunerea tehnică un plan detaliat de implementare, cu termene pe etape — acest plan constituie criteriu de eligibilitate și va fi evaluat ca atare. Calendarul definitiv de conectare/etapizare a autorităților publice locale va fi însă stabilit de Autoritatea Contractantă la semnarea contractului, pe baza planului de implementare propus de Consultant și a necesităților operaționale ale Beneficiarului. Ofertanții vor dimensiona propunerea tehnică ținând cont că implicarea efectivă a APL poate fi graduală, fără a presupune conectarea simultană a tuturor autorităților publice locale de nivelul II din prima etapă.

Da. Conform pct. 39 din Documentația standard, în cazul unei asocieri, cerințele de capacitate tehnică și profesională (inclusiv certificările ISO 9001 și ISO 27001) pot fi îndeplinite prin cumul proporțional sarcinilor ce revin fiecărui asociat. Este, deci, suficient ca certificatul relevant să fie deținut de membrul asocierii care execută efectiv partea de contract corespunzătoare standardului respectiv (managementul calității, respectiv securitatea informației) — nu este necesar ca fiecare membru sau liderul asocierii să dețină ambele certificate.

Da. Conform pct. 42-43 din Documentația standard, cerința privind cel puțin 2 proiecte GIS finalizate — fiind o cerință de capacitate tehnică și profesională — poate fi îndeplinită fie de un membru al asocierii (proporțional sarcinilor ce îi revin, conform pct. 41), fie prin susținerea unui terț care va executa efectiv componenta GIS, prin prezentarea angajamentului ferm (Anexa nr. 16/18) și a declarației terțului susținător tehnic și profesional (Anexa nr. 17/19/20), declarate în DUAE și prezentate la solicitarea autorității contractante. Terțul susținător trebuie să îndeplinească el însuși criteriile de selecție relevante pentru partea susținută și să nu se afle în situații de excludere.

Conform pct. 3.4 din proiectul de contract, achitarea se efectuează separat pentru fiecare dintre cele 8 etape indicate (corespunzătoare, în mare parte, etapelor descrise la pct. 6 din caietul de sarcini, cu adăugarea etapei finale de „Lansare în producție"), în termen de 30 de zile de la predarea și recepționarea fără obiecții a Raportului de îndeplinire a etapei respective. Repartizarea valorică a prețului contractului pe cele 8 etape nu este prestabilită de Autoritatea Contractantă — aceasta urmează a fi indicată de ofertant în Specificația de preț (Anexa nr. 23 la Documentația standard), parte a propunerii financiare, corelată cu planul detaliat de implementare pe etape prevăzut la pct. 6 din caietul de sarcini.

În cazul depunerii garanției pentru ofertă sub formă de garanție bancară urmează a fi respectată anexa nr.9 la documentația standard, cu indicarea băncii corespondente din Republica Moldova, Valuta liber convertibilă conform cursului valutar stabilit de BNM, care va acoperi 1% din valoarea ofertei depuse în lei MDL de către ofertant, pe întreaga perioadă de valabilitate a ofertei. Conform documentației standard pct. 52. În cazul unei asocieri, garanția pentru ofertă se depune de liderul asociației. Dacă liderul asocierii conform acordului/contractului de asociere împuterniceste unul din asociați să depună garanția pentru ofertă, atunci va fi acceptată această garanție pentru ofertă