privind achiziționarea: Servicii de crearea a Sistemului informațional „Registrul de stat VioData”

Bună ziua, Referitor la solicitarea privind perioada de estimare a Raportului de Cost Total de Proprietate (TCO), vă comunicăm următoarele: Ofertanții vor elabora Raportul TCO în conformitate cu prevederile Caietului de Sarcini, respectiv pentru o perioadă minimă de 3 ani cu indicarea costul complet al unui sistem pe întreaga durată de viață a sistemului. În cadrul raportului TCO este necesar de inclus următoarele aspecte minime: 1. Costuri inițiale (CAPEX) 2. Costuri operaționale (OPEX) 3. Costuri de infrastructură 4. Costuri de licențiere (dacă există) 5. Costuri de interoperabilitate 6. Costuri de securitate și conformitate 7. Costuri de final de viață (scoaterea din exploatare) Dorim să precizăm că Raportul TCO este distinct de oferta financiară prezentată de ofertant, după cum urmează: Oferta financiară reprezintă costurile aferente implementării contractului (analiză, dezvoltare, integrare, testare, lansare, precum și, după caz, mentenanța inclusă în perioada contractuală) și constituie baza evaluării financiare a ofertelor; Raportul TCO reprezintă o analiză estimativă, extinsă, a costurilor totale asociate ciclului de viață al sistemului (inclusiv operare, mentenanță, infrastructură, securitate, extinderi și scoatere din exploatare), pe o perioadă multianuală, care poate depăși durata contractului.

Întrebarea: 1. Referitor la CS, Cap. 3, pag. 4 Proiectarea și dezvoltarea Sistemului informațional „Registrul de stat VioData”, incluzând funcționalități de bază precum: 4. Integrarea cu serviciile de suport destinate asistenței și protecției victimelor (adăposturi, consiliere psihologică și juridică). Vă rugăm să prezentați o listă exhaustivă cu „serviciile de suport destinate asistenței și protecției victimelor” cu care va fi necesară integrarea sistemului informatic VioData, precum și capabilitățile de integrare ale „serviciilor” respective, cât și fluxurile de date care se doresc implementate prin integrarea VioData cu „serviciile” respective. Răspunsul: Lista de suport destinate asistenței și protecției victimelor include următoarele categorii: Servicii sociale – Servicii de asistență socială și prestații sociale (ATAS/STAS) • Conectarea cu sistemul informațional „eSocial ” prin MConnect. Posesor al sistemului Ministerul Muncii și Protecției Sociale. Fluxurile de date vor fi definitivate în anexa tehnică pivind schimbul de date prin MConnect. Servicii de adăpost – centre de plasament pentru victime, centre de criză. • Conectarea cu registrul electronic al Centrului de Justiție Familială în subordinea Inspectoratului General de Poliție. Lista instituțiilor și organizațiilor de suport potențiale pentru conectare https://anpcv.gov.md/ro/asistenta/lista-institutiilor *Notă – majoritatea instituțiilor nu posedă un sistem informațional sau registru electronic. Servicii medicale – serviciile de asistență medicală primară și centrele de medicină legală. • SI „Asistență Medicală Primară” (SIA AMP) – conectarea cu SIA AMP prin intermediu MConnect. Fluxurile de date vor fi definitivate în anexa tehnică privind schimbul de date prin MConnect. • Centre de medicină legală – nu există sistem informațional. Servicii juridice – serviciul de asistență juridică garantată de stat. • Sistemul informațional CNAJGS (asistență juridică garantată de stat). Sistemul nu este parte a platformei de interoperabilitate MConnect. Fluxurile de date vor fi definitivate în cadrul unui acord de schimb de date. HG Nr. 39 din 29-01-2025 cu privire la aprobarea Conceptului Sistemului informațional „e-Social” https://www.legis.md/cautare/getResults?doc_id=146972&lang=ro Pagina web al Centrului de Justiție Familială https://cjf.md Întrebarea: 2. Referitor la CS, Cap. 3, pag. 4 Proiectarea și dezvoltarea Sistemului informațional „Registrul de stat VioData”, incluzând funcționalități de bază precum: 5.Implementarea planurilor de acțiune/intervenție personalizate, care să includă măsuri de protecție, sprijin psihologic și asistență legală. Vă rugăm să detaliați această cerință. Vă rugăm să confirmați dacă prin „implementarea planurilor de acțiune / intervenție personalizate” se are în vedere implementarea în sistemul informatic VioData a structurilor de date relevante pentru introducerea și monitorizarea planurilor respective. Răspunsul: Planurilor de acțiune/intervenție personalizate pentru victimele violenței sunt realizate în modulul de management de caz în sistemul informațional “eSocial”. Cerința se referă explicit la implementarea structurilor de date și workflow care să permită importarea datelor din eSocial. Structură minimă: • ID plan / ID caz • Statut caz • Lista acțiuni (listă) • Responsabil • Termen de implementare Întrebarea: 3. Referitor la CS, Cap. 3, pag.4 Proiectarea și dezvoltarea Sistemului informațional „Registrul de stat VioData”, incluzând funcționalități de bază precum: 6. Monitorizarea cazurilor de violenţă, în mediul offline și online și urmărirea referirilor către serviciile de suport. Vă rugăm să detaliați / exemplificați această cerință, în special cu privire la „monitorizarea cazurilor de violență, în mediul offline și online”. Răspunsul: Registrul de stat VioData urmează să fi conectat la instrumentul de monitorizare a cazurilor de violență în mediul online dezvoltat de către UNFPA. Astfel, monitorizarea cazurilor de violenţă, în mediul offline se referă la toate cazurile de violență care sunt notificate în cadrul sistemului (raportări poliție, sănătate etc.) iar cazurile online se referă la cazurile monitorizare de sistemul UNFPA (pentru detalii a se vedea cerințele 5.3.1.4). Integrarea acestora este necesară doar la nivel de raportare. Întrebarea: 4. Referitor la CS, Cap. 3, pag. 4 Proiectarea și dezvoltarea Sistemului informațional „Registrul de stat VioData”, incluzând funcționalități de bază precum: 10. Interoperabilitate cu sistemele de informații guvernamentale. Vă rugăm să prezentați o listă exhaustivă cu „sistemele de informații guvernamentale” (altele decât cele disponibile prin serviciile e-Guvernare) cu care va fi necesară integrarea sistemului informatic VioData, precum și capabilitățile de integrare ale sistemelor respective, cât și fluxurile de date care se doresc implementate prin integrarea VioData cu sistemele respective. Răspunsul: Sisteme informaționale care conțin date referitor la prevenire și combatere a violenței împotriva femeilor și a violenței în familie Domeniul de competență: - Evidența Populației Sisteme Informaționale (SI) și Instituția: - SIA Registrul de Stat al Populației (Agenția Servicii Publice) Flux de date și obiecte informaționale: - Preluarea datelor personale ale victimelor și agresorilor pe baza IDNP Capabilități de integrare: - MConnect. Domeniul de competență: - Muncă și protecție socială Sisteme Informaționale (SI) și Instituția: - SI „Asistență Socială” (MMPS) - SI “eSocial” (Ministerul Muncii și Protecției Sociale); - SI „Vulnerabilitatea energetică (MMPS); - SI Determinarea Dizabilității și a Capacității de Muncă (Consiliului Național pentru Determinarea Dizabilității și Capacității de Muncă), - SI de înregistrare cu statut de șomer (Agenția Națională de Ocupare a Forței de Muncă). Flux de date și obiecte informaționale: - Schimb de date privind serviciile sociale, prestațiile acordate, statul și evitarea dublei raportări a cazurilor de violență. - Date privind determinarea statutului de șomer sau a dizabilității în cazurile care implică persoane vulnerabile. Capabilități de integrare: - MConnect. Domeniul de competență: - Sănătate. Sisteme Informaționale (SI) și Instituția: - SI „Asistență Medicală Primară” (Ministerul Sănătății). Flux de date și obiecte informaționale: - Recepționarea datelor medicale. Capabilități de integrare: - MConnect. Domeniul de competență: - Educație și cercetare Sisteme Informaționale (SI) și Instituția: - SI de Management în Educație (Ministerul Educației și Cercetării) Flux de date și obiecte informaționale: - Date despre instituția de învățământ, prezență, transferuri școlare ale minorilor. Capabilități de integrare: Nu există capacitate de furnizare a datelor prin MConnect Domeniul de competență: - Poliție Sisteme Informaționale (SI) și Instituția: - SI „Registrul informațiilor criminalistice și criminogene” (Inspectoratul Ggeneral de Poliției); - SI de evidență a contravențiilor și cauzelor contravenționale. (IGP) Flux de date și obiecte informaționale: - Preluarea antecedentelor penale și a datelor despre profilul de risc al agresorului. - Monitorizarea sancțiunilor aplicate pentru acte de violență ce nu întrunesc elementele unei infracțiuni. Capabilități de integrare: - MConnect. Domeniul de competență: - Procuratura Sisteme Informaționale (SI) și Instituția: - SI „Urmărire penală: E-Dosar” (Procuratura Generală). Flux de date și obiecte informaționale: - Schimb de date privind stadiul urmăririi penale, măsurile preventive aplicate și deciziile procurorilor. Capabilități de integrare: - MConnect. Domeniul de competență: - Instanțe de judecată. Sisteme Informaționale (SI) și Instituția: - SI „Programul Integrat de Gestionare a Dosarelor (Agenția Digitalizare în Justiție și Administrare Judecătorească). Flux de date și obiecte informaționale: - Monitorizarea ordonanțelor de protecție emise de instanțele de judecată. - Schimb de date privind hotărîrile și deciziile instanțelor de judecată. Capabilități de integrare: - MConnect. Domeniul de competență: - Penitenciar Sisteme Informaționale (SI) și Instituția: - SI „Registrul persoanelor reținute, arestate și condamnate” (Administrația Națională a Penitenciarilor); *În dezvoltare. Flux de date și obiecte informaționale: - Statutul de detenție al agresorului, data eliberării, locația de detenție. Capabilități de integrare: La moment nu există capacitate de furnizare a datelor. Domeniul de competență: - Asistență judiciară garantată de stat. Sisteme Informaționale (SI) și Instituția: - SI al Consiliului Național pentru Asistență Juridică Garantată de Stat (CNAJGS). Flux de date și obiecte informaționale: - Înregistrarea referirilor pentru asistență juridică gratuită. Capabilități de integrare: Nu există capacitate de furnizare a datelor prin Mconnect, va fi necesar de încheiat un acord pentru schimb de date. Domeniul de competență: - Instrument de monitorizare social media. Sisteme Informaționale (SI) și Instituția: - Instrument de monitorizare UNFPA, *În dezvoltare Flux de date și obiecte informaționale: - Monitorizarea cazurilor potențiale de violență în mediul online. Capabilități de integrare: - Va fi încheiat acord pentru schimb de date. Întrebarea: 5. referitor la CS, Cap. 5, pag. 8 Pentru dezvoltarea backend, se recomandă utilizarea Django, Flask sau Node.js Vă rugăm să confirmați că enumerarea din această cerința este una exemplificativă și nu limitativă (că nu vor putea fi utilizate doar aceste tehnologii pentru dezvoltare backend). În speță, vă rugăm să confirmați că pentru dezvoltarea componentelor backend poate fi utilizat limbajul Java (ex: distribuția OpenJDK, care este open-source, Java fiind unul dintre cele mai răspândite limbaje de programare la nivel mondial). Răspunsul: În vederea asigurării conformității SI RE VioData cu arhitectura digitală guvernamentală a Republicii Moldova, prestatorul are obligația de a se familiariza, analiza și aplica prevederile tehnice, metodologice și arhitecturale prezentate în platforma eGov4Dev. Pentru cerințele backend a se consulta “Tools and technologies” disponibil pe pagina web: https://egov-moldova.github.io/egov4dev/ . Prin urmare, este permisă utilizarea tehnologiilor open-source precum Java (ex. Distribuția OpenJDK), cu condiția demonstrării conformității cu standardele eGov4Dev și a integrării corecte în arhitectura guvernamentală. Întrebarea: 6. Referitor la CS, cap. 5.1, pag. 8 Sistemul informațional „Registrul de stat VioData” trebuie să fie disponibil în limbile română, rusă și engleză. Limba implicită va fi româna cu acuratețea de 100%. Vă rugăm să precizați dacă disponibilitatea sistemului VioData în limba rusă este obligatorie sau opțională. Răspunsul: Disponibilitatea sistemului VioData în limba rusă este obligatorie. Întrebarea: 7. Referitor la CS, cap. 5.4.1, pag. 10 5.4.1.2. Tranzițiile între stările cazului trebuie să fie guvernate de reguli de business configurabile. Vă rugăm să detaliați / exemplificați această cerință. Vă rugăm să confirmați că cerința NU se referă la implementarea unei componente de tip „motor reguli de business”. Răspunsul: Cerința 5.4.1.1. privind tranzițiile între stările cazului guvernate de reguli de business configurabile trebuie interpretată în sensul implementării unui mecanism de control al ciclului de viață al cazului, bazat pe reguli definite și parametrizabile la nivelul aplicației. Tranzițiile între stările cazului (ex. „deschis”, „în desfășurare”, „referit”, „închis”) vor fi permise doar dacă sunt îndeplinite condițiile stabilite prin reguli de business, care pot include, fără a se limita la: • respectarea ordinii logice a fluxului operațional (workflow); • verificarea rolului utilizatorului care efectuează acțiunea; • existența unor date sau acțiuni obligatorii (ex. evaluare de risc, plan de intervenție); • absența unor restricții active (ex. ordine de protecție active). Prin „configurabile” se înțelege că aceste reguli pot fi definite și ajustate fără modificări majore de cod, prin mecanisme de configurare la nivelul aplicației (ex. parametri, nomenclatoare, reguli stocate în baze de date sau fișiere de configurare). Cerința nu implică obligatoriu implementarea unui motor dedicat de reguli de business (Business Rules Engine), ci poate fi realizată printr-un mecanism standard de validare și control al tranzițiilor integrat în logica aplicației. Întrebarea: 8. Referitor la CS, cap. 5.7.1, pag. 12 5.7.1.1. Sistemul trebuie să permită generarea rapoartelor standard și personalizate. Vă rugăm să prezentați o listă exhaustivă cu rapoarte standard ce fac obiectul implementării de către Prestator. Răspunsul: Raport statistic conform Setului de indicatori naționali în domeniul prevenirii și combaterii violenței împotriva femeilor și a violenței în familie, aprobate în baza Hotărîrii de Guvern. Întrebarea: 9. Referitor la CS, cap. 5.7.1, pag. 12 5.7.1.3. Sistemul trebuie să recepționeze rezultatele de analiză a tendințelor pe rețelele de socializare și să genereze rapoarte personalizat în baza acestor date. Vă rugăm să confirmați că cerința se referă la capabilitatea sistemului VioData să expună mecanisme de recepție a rezultatelor de analiză a tendințelor de pe rețelele de socializare și NU se referă la capabilitatea sistemului de a realiza / de a face propriu-zis aceste analize de tendințe pe rețelele de socializare. Răspunsul: Confirmăm, VioData urmează doar să expună mecanisme de recepție a rezultatelor de analiză a tendințelor de pe rețelele de socializare și NU se referă la capabilitatea sistemului de a realiza / de a face propriu-zis aceste analize de tendințe pe rețelele de socializare. Registrul de stat VioData urmează să fi conectat la instrumentul de monitorizare a cazurilor de violență în mediul online dezvoltat de către UNFPA. Întrebarea: 10. Referitor la CS, cap. 5.7.2, pag. 12 5.7.2.1. Sistemul trebuie să includă tablouri de bord interactive și configurabile. Vă rugăm să clarificați dacă cerința se referă la configurarea tablourilor de bord de către administratorii sistemului VioData. Răspunsul: Cerința 5.7.2.1. NU implică dezvoltare personalizată de tablouri de bord (custom-made). Configurabilitate tablourilor de bord se realizează prin filtre, indicatori și vizualizări. Întrebarea: 11. Referitor la CS, cap. 5.10, pag. 13 5.10. Documentele de bază ale registrului de stat VioData Având în vedere cerințele din acest capitol, una dintre modalitățile de implementare ale acestora este utilizarea unui sistem informatic de tip DMS (Document Management System) existent deja în circuitul comercial (COTS: Commercial-Off-The-Shelf). Acest mod de implementare ar permite obținerea rezultatelor / implementarea funcționalităților solicitate într-un interval de timp și efort mai scăzut, față de implementarea de la zero a cerințelor din acest capitol. Vă rugăm să confirmați dacă este permisă utilizarea acestei abordări (includerea în sistemul VioData a unui DMS de tip COTS) și care sunt condițiile specifice pentru această abordare. Răspunsul: DA, este permisă utilizarea unui DMS COTS, cu condiția ca aceasta să fie complet integrată în arhitectura SI RS VioData, să respecte cerințele funcționale privind gestionarea documentelor, să asigure interoperabilitatea prin MConnect, controlul accesului prin MPass și jurnalizarea prin MLog, precum și să permită asocierea documentelor cu obiectele informaționale ale sistemului. Condiții obligatorii pentru utilizarea DMS 1. Integrare completă în VioData (nu standalone) • DMS trebuie integrat la nivel de UI (embedded sau integrat) și backend (API) • Utilizatorul nu trebuie să „iasă” din VioData 2. Cartografierea pe obiecte informaționale VioData. DMS trebuie să suporte asociere “document”  “caz” 3. Respectarea RBAC + MPass. Control acces conform rolurilor VioData și integrare cu MPass (SSO) 4. Audit și jurnalizare – integrare cu Mlog pentru audit. 5. Interoperabilitate cu expunerea API pentru export documente Întrebarea: 12. Referitor la CS, cap. 6.1, pag. 21 • Tehnologii recomandate (Technology stack): Frontend: Aplicațiile web sunt construite cu MudBlazor - MudBlazor – NuGet: MudBlazor – componente reutilizabile ale interfeței utilizator - Blazor Server / WebAssembly – pentru aplicații interactive în NET Având în vedere cerințele din Caietul de Sarcini, capitolul 5, pagina 8, și anume „pentru dezvoltarea frontend, utilizarea framework-urilor React, Vue.js sau Angular, pentru o interfață receptivă și ușor de utilizat.”, vă rugăm să confirmați că cerințele din acest capitol (6.1) nu sunt restrictive, ci exemplificative. În clar, vă rugăm să confirmați că este permisă utilizarea framework-urilor React, Vue.js sau Angular pentru dezvoltarea frontend. Răspunsul: Tehnologiile backend indicate în capitolul 6.1 au caracter exemplificativ și nu sunt restrictive ca limbaj sau framework. Cu toate acestea, în conformitate cu cerințele Caietului de sarcini și cu documentația eGov4Dev, soluția propusă trebuie să respecte principiile arhitecturale, de interoperabilitate și de integrare în ecosistemul guvernamental (inclusiv utilizarea MConnect, MPass, MLog și alte servicii relevante). Prin urmare, este permisă utilizarea tehnologiilor open-source precum Django, Flask, Node.js sau Java (OpenJDK), cu condiția demonstrării conformității cu standardele eGov4Dev și a integrării corecte în arhitectura guvernamentală. Întrebarea: 13. Referitor la CS, cap. 6.1, pag. 21 o Backend: Logica de business este implementată în cadrul ecosistemului.NET * ASP.NET Core – NuGet: Microsoft.AspNetCore.* – pentru servicii REST și aplicații web scalabile * Entity Framework Core – NuGet: Microsoft.EntityFrameworkCore – pentru acces la baze de date relaționale * FluentValidation – NuGet: FluentValidation – pentru validări declarative * Swashbuckle.AspNetCore – NuGet: Swashbuckle.AspNetCore – pentru generarea documentației Swagger Având în vedere cerințele din Caietul de Sarcini, capitolul 5, pagina 8, și anume „Pentru dezvoltarea backend, se recomandă utilizarea Django, Flask sau Node.js”, precum și întrebarea adresată anterior privind utilizarea Java pentru dezvoltarea backend, vă rugăm să confirmați că cerințele din capitolul 6.1 nu sunt restrictive, ci sunt exemplificative. În clar, vă rugăm să confirmați că pentru dezvoltarea backend este permisă utilizarea Django, Flask sau Node.js sau Java (Open JDK). Răspunsul: Tehnologiile backend indicate în capitolul 6.1 au caracter orientativ și nu limitează utilizarea altor tehnologii. Alegerea stack-ului backend este permisă în mod flexibil, cu condiția ca soluția propusă să fie pe deplin compatibilă cu cerințele și principiile stabilite în platforma eGov4Dev, inclusiv în ceea ce privește interoperabilitatea, integrarea cu serviciile guvernamentale și arhitectura sistemului. Astfel, utilizarea tehnologiilor open-source precum Django, Flask, Node.js sau Java (OpenJDK) este acceptată, în măsura în care acestea permit implementarea conformă a cerințelor sistemului și integrarea corectă în ecosistemul digital guvernamental. Întrebarea: 14. Referitor la CS, cap. 6.2, pag. 21 • Implementarea proiectului ar trebui să includă un mediu de dezvoltare pentru scrierea, testarea și depanarea codului sistemului Vă rugăm să clarificați dacă mediul de dezvoltare va fi găzduit în MCloud sau poate fi găzduit în infrastructura Prestatorului. Răspunsul: Atât mediul de dezvoltare, cât și mediul de producție vor fi găzduite în Platforma Cloud Guvernamentală (MCloud). Întrebarea: 15. Referitor la CS, cap. 6.4, pag. 22 6.4. GPS Geo-etichetare Vă rugăm să detaliați care este necesitatea utilizării componentei de Geo-etichetare, deoarece nu am regăsit-o printre scenariile operaționale / cerințele funcționale ale sistemului informațional VioData. Răspunsul: Funcționalitatea de geo-etichetare (GPS) nu este corelată explicit cu scenariile operaționale definite în Caietul de sarcini. În vederea asigurării coerenței funcționale, se propune integrarea acesteia în cadrul scenariului operațional SO-01 – Înregistrarea unui caz de violență, prin posibilitatea de a înregistra locația incidentului (adresă, localitate și/sau coordonate GPS, după caz). Implementarea acestei funcționalități va fi realizată într-un mod opțional și proporțional cu necesitățile operaționale, cu respectarea cerințelor de protecție a datelor și a controlului accesului. Întrebarea: 16. Referitor la CS, cap. 6.5, pag. 22 • Sistemul informațional „Registrul de stat VioData” ar trebui să cripteze toate datele în tranzit utilizând TLS Vă rugăm să confirmați că Autoritatea Contractantă va pune la dispoziție certificatul TLS/SSL necesar pentru implementarea acestei cerințe. Răspunsul: Criptarea datelor în tranzit prin TLS va fi implementată conform cerințelor Caietului de sarcini și principiilor eGov4Dev. Certificatele digitale necesare (TLS/SSL și, după caz, certificate X.509 pentru mecanismele de mutual TLS utilizate în interoperabilitate) vor fi furnizate și gestionate de către Serviciul Tehnologia Informației și Securitate Cibernetică (STISC), în conformitate cu arhitectura guvernamentală și procedurile de integrare aplicabile. Prestatorul va asigura implementarea tehnică a mecanismelor de securitate și integrarea sistemului utilizând certificatele puse la dispoziție. Întrebarea: 17. Referitor la CS, cap. 6.9, pag. 23 • Sistemul trebuie actualizat periodic cu funcționalități noi, bazate pe feedback-ul utilizatorilor și nevoile în evoluție după faza pilot. În conformitate cu prevederile art. 76 alin. (1) lit. c) și alin. (4) din Legea nr. 131/2015 privind achizițiile publice, modificările unui contract de achiziție publică sunt permise fără organizarea unei noi proceduri de achiziție doar în limita unor praguri valorice și de conținut bine definite, pentru a nu altera obiectul inițial al contractului. Cerința citată nu precizează: Volumul maxim al funcționalităților noi (exprimat în ore-om, puncte funcționale sau zile-persoană) care vor fi solicitate pe durata contractului după faza pilot; Criteriile obiective pe baza cărora se va stabili că o solicitare constituie o „funcționalitate nouă" față de o remediere de eroare (bug fix) sau o adaptare minoră inclusă în mentenanță; Procesul de aprobare și prioritizare a solicitărilor de noi funcționalități, respectiv autoritatea care validează feedback-ul utilizatorilor ca bază pentru modificări; Plafonul valoric al modificărilor cumulate, raportat la limita de 15% din valoarea inițială a contractului prevăzută de art. 76 alin. (4) din Legea nr. 131/2015, dincolo de care ar fi necesară o nouă procedură de achiziție. Solicităm autorității contractante să precizeze: a) Care este volumul total estimat (ore-om sau zile-persoană) rezervat pentru dezvoltarea de funcționalități noi pe întreaga durată a contractului, după faza pilot? b) Va fi elaborat un Registru de Modificări (Change Request Log) cu procedură formalizată de aprobare, sau funcționalitățile noi vor fi solicitate ad-hoc? Dacă da, care este numărul maxim de cereri de modificare anticipate? c) În lipsa unui plafon definit, cum va garanta autoritatea contractantă că solicitările cumulate nu depășesc pragul prevăzut la art. 76 alin. (4) din Legea nr. 131/2015, evitând astfel necesitatea inițierii unei noi proceduri de achiziție care ar invalida retroactiv executarea contractului? Răspunsul: Caietul de sarcini solicită ofertanților să includă în Raportul TCO și în Estimarea de efort resursele necesare pentru ciclul de viață al sistemului pe 3 ani, inclusiv modernizarea. Volumul specific de ore-om pentru "funcționalități noi" post-pilot va fi limitat la ajustările rezultate strict din Raportul de Pilotare , care are rolul de a rafina designul înainte de implementarea la scară largă. Orice dezvoltare majoră ulterioară care depășește scopul inițial va face obiectul unor proceduri separate, conform legii. Implementarea va urma o metodologie Agile/Hibridă. Toate modificările vor fi gestionate prin: • Grupul comun de lucru format din reprezentanții Prestatorului și Beneficiarului. • Validarea cerințelor în Etapa I și actualizarea acestora în baza feedback-ului din faza de testare/pilotare (Etapa IV). • Matricea de trasabilitate va servi drept instrument de control pentru a distinge între cerințele obligatorii inițiale și solicitările suplimentare. ANPCV va monitoriza execuția contractului astfel încât: 1. Mentenanța corectivă și adaptivă (inclusă în prețul contractului pentru primele 12 luni) să nu fie confundată cu modificări de substanță. 2. Toate livrabilele sunt verificate în termen de 5 zile lucrătoare , iar acceptanța finală se face doar pe baza conformității cu cerințele funcționale obligatorii. 3. Solicitările de „funcționalități noi” menționate la cap. 6.10 se referă la optimizări de utilizabilitate rezultate din faza de pilot, necesare pentru atingerea indicatorilor de performanță asumați, și nu la extinderi de domeniu care să încalce pragurile valorice legale. Întrebarea: 18. Referitor la CS, cap. 6.9, pag. 23 • Dezvoltatorii trebuie să ofere întreținere corectivă și adaptivă pentru sistem timp de până la un an după implementarea sistemului. În contextul în care Legea nr. 131/2015 privind achizițiile publice impune ca obiectul contractului să fie definit cu suficientă precizie pentru a permite evaluarea comparabilă a ofertelor, iar Standardul național de achiziții SNA-04 recomandă delimitarea clară a prestațiilor incluse în contract față de cele care pot face obiectul unor acte adiționale, solicităm clarificări cu privire la componenta de întreținere adaptivă, aceasta fiind prin natura sa nedeterminată în volum și conținut. Spre deosebire de întreținerea corectivă – al cărei scop este delimitat obiectiv (remedierea defectelor față de specificațiile agreate), întreținerea adaptivă presupune modificarea sistemului ca răspuns la schimbări externe: legislative, organizaționale, de infrastructură sau de mediu tehnologic. În forma actuală, cerința nu stabilește: - Tipurile de schimbări externe care vor declanșa obligația de intervenție adaptivă (ex.: modificări ale cadrului normativ național, schimbări ale platformelor de integrare, actualizări ale sistemului de operare/baze de date); - Volumul maxim al intervențiilor adaptive, exprimat în ore-om sau zile-persoană, inclus în prețul contractului; - Pragul de complexitate de la care o intervenție adaptivă încetează a fi acoperită de contract și devine o dezvoltare nouă, supusă procedurii de la art. 76 din Legea nr. 131/2015; - Termenele de reacție și de execuție diferențiate față de cele aplicabile întreținerii corective, pentru a permite ofertanților să dimensioneze echipa și costurile aferente. Solicităm autorității contractante să precizeze: a) Care sunt categoriile concrete de evenimente externe (modificări legislative, schimbări de infrastructură, actualizări ale sistemelor terțe cu care se integrează soluția) față de care se va solicita întreținere adaptivă pe parcursul anului post-implementare? b) Care este volumul maxim estimat (ore-om sau zile-persoană) alocat întreținerii adaptive în cadrul contractului, distinct de cel al întreținerii corective, astfel încât ofertanții să îl poată reflecta în mod transparent în oferta financiară? c) Care este criteriul de delimitare între o intervenție adaptivă acoperită de prezentul contract și o funcționalitate nouă sau o modificare substanțială care ar impune încheierea unui act adițional sau inițierea unei noi proceduri de achiziție, în conformitate cu art. 76 alin. (4) din Legea nr. 131/2015? d) În cazul în care pe durata anului post-implementare intervine o modificare legislativă majoră cu impact semnificativ asupra sistemului, există un mecanism contractual de plafonare a efortului solicitat ofertantului, sau acesta este nelimitat în cadrul prețului fix ofertat? Motivarea relevanței întrebării: În absența acestor delimitări, întreținerea adaptivă reprezintă o obligație cu perimetru nedefinit, ceea ce face imposibilă calcularea unui preț ferm și complet, contrar principiului transparenței și al eficienței utilizării fondurilor publice prevăzute la art. 7 din Legea nr. 131/2015. Totodată, ofertanții care vor interpreta diferit sfera acestei obligații vor depune oferte financiare incomparabile, viciind evaluarea și clasamentul final. Răspunsul: Întreținerea adaptivă pe parcursul celor 12 luni post-implementare se referă strict la menținerea funcționalității SI RS VioData în raport cu evoluția ecosistemului digital guvernamental existent la momentul recepției. Categoriile concrete includ: • Actualizări ale platformelor de integrare: Ajustări tehnice necesare ca urmare a actualizărilor interfețelor API ale serviciilor guvernamentale comune (MPass, MSign, MNotify, MLog, MConnect). • Schimbări de infrastructură MCloud: Adaptarea configurațiilor sistemului la modificările tehnice survenite în platforma de găzduire guvernamentală. • Actualizări de securitate și mediu tehnologic: Aplicarea patch-urilor pentru tehnologiile open-source utilizate (.NET, PostgreSQL, Docker, Kubernetes) pentru a răspunde noilor cerințe de securitate cibernetică. • Ajustări legislative minore: Modificări ale formatelor de raportare sau ale nomenclatoarelor interne rezultate din actualizări ale cadrului normativ care nu alterează arhitectura de bază a sistemului. ANPCV estimează un volum de aproximativ 15% din efortul total de dezvoltare pentru componenta de mentenanță (corectivă și adaptivă cumulată) pe durata primului an. Ofertanții trebuie să reflecte acest efort în Raportul TCO pentru o perioadă de 3 ani, permițând astfel o evaluare financiară transparentă. Criteriul de delimitare între intervenție adaptivă și funcționalitate nouă este realizat de grupul comun de lucru pe baza următoarelor criterii: • Întreținere adaptivă: Intervenția care are ca scop menținerea sistemului operațional conform specificațiilor inițiale în condițiile schimbării mediului extern (ex: schimbarea versiunii unui API existent). • Funcționalitate nouă: Orice solicitare care introduce un nou Obiect Informațional, un nou Contur Funcțional nespecificat în Conceptul aprobat prin HG nr. 530/2025 sau care modifică fluxul operațional end-to-end (Use Case) într-un mod care necesită reproiectarea bazei de date. • Modificările substanțiale vor fi tratate conform Art. 76 din Legea nr. 131/2015, prin proceduri separate sau acte adiționale, în limita pragului de 15%. Întrebarea: 19. Referitor la CS, pag. 27 Asumarea serviciilor implică acordarea garanției asupra SI RS VioData pentru o perioadă de minim 12 luni după încetarea contractului. Vă rugăm să confirmați că cerința se referă la acordarea garanției pentru o perioadă de minim 12 luni după punerea în producție a sistemului informațional VioData. Răspunsul: Confirmăm faptul că cerința se referă la acordarea garanției pentru o perioadă de minimum 12 luni de la data punerii în producție și semnării procesului-verbal de recepție finală a sistemului informațional RS VioData. Pentru evitarea oricăror ambiguități interpretative, precizăm următoarele corelații cu etapele proiectului: • Corelarea cu Etapele (Cap. 6.1): Garanția și mentenanța fac obiectul Etapei VI, care începe imediat după finalizarea Etapei V (Lansarea și darea în exploatare). • Momentul declanșării: Perioada de 12 luni curge de la momentul în care sistemul este deplin funcțional în mediul de producție și a fost acceptat de către ANPCV, marcând finalizarea obligațiilor de dezvoltare și implementare. • Natura termenului: Sintagma „după încetarea contractului” din textul original se referă la încetarea fazei de realizare/dezvoltare a produsului (proiectul de investiție propriu-zis), după care începe perioada de suport post-implementare și operare sub garanție. Prin urmare, oferta financiară și planificarea resurselor trebuie să acopere această perioadă de 12 luni de asistență tehnică, mentenanță corectivă și adaptivă, calculată de la recepția sistemului. Întrebarea: 20. Referitor la Anunț participare, pct. 25. Factori evaluare. Denumirea factorului: „Experiența ofertantului în dezvoltarea sistemelor informaționale” Vă rugăm să confirmați că pentru obținerea punctajului pentru acest factor pot fi prezentate și sisteme informaționale implementate în afara Republicii Moldova (în speță, sisteme informaționale implementate în România). Răspunsul: Confirmăm faptul că, în procesul de evaluare a experienței similare, pot fi prezentate sisteme informaționale implementate atât în Republica Moldova, cât și în afara țării, inclusiv în România, cu condiția ca acestea să demonstreze competențe tehnice și funcționale relevante pentru obiectul prezentului Caiet de Sarcini. Întrebarea: 21. Referitor la Termen depunere Având în vedere complexitatea cerințelor privind sistemul informatic și elaborarea ofertelor, precum și perioada de Sărbători Pascale ce se suprapune peste perioada de depunere a ofertelor, vă rugăm să prelungiți termenul de depunere cu cel puțin 10 (zece) zile lucrătoare. Răspunsul: ANPCV anunță prelungirea termenului de depunere a ofertelor.