Servicii de implementare a soluției informatice de operațiuni bancare (licențe, servicii de implementare și servicii de garanție)

BNM confirmă că politicile standard de licențiere ale producătorilor (ex. Oracle) trebuie respectate. În acest context, cerința CL.12 trebuie interpretată astfel: • în situația în care, conform politicilor producătorului, licențele trebuie activate/achiziționate la momentul instalării sau utilizării (anterior Go-Live), ofertantul va respecta aceste politici; • toate costurile aferente licențelor pe perioada de implementare (până la Go-Live) vor fi suportate de către ofertant și incluse în ofertă; • la momentul Go-Live, ofertantul va asigura că serviciile de suport și mentenanță pentru licențe sunt valabile pentru o perioadă de minimum 12 luni, astfel încât să acopere perioada de garanție.

Având în vedere cerințele și constrângerile ce reies din procedura de achiziție, Vă comunicăm că BNM nu intenționează să încheie acorduri directe cu producătorii pentru acoperirea fazelor de implementare. Ofertantul este responsabil să asigure toate elementele necesare livrării soluției. În situația în care, conform politicilor producătorului, licențele trebuie activate la momentul instalării/utilizării (anterior Go-Live) și nu există opțiuni de utilizare în regim trial sau echivalent, ofertantul va respecta aceste politici și va include în ofertă costurile aferente perioadei de implementare. Livrarea licențelor poate avea loc înainte de Go-Live, în funcție de necesitățile de implementare, însă facturarea acestora va avea loc exclusiv la etapa de Go-Live, în conformitate cu condițiile de plată stabilite. Ofertantul are libertatea de a propune modele de licențiere conforme cu politicile producătorului (ex. aranjamente temporare, inclusiv încheierea contractelor tripartide, sau alte mecanisme comerciale), astfel încât să gestioneze perioada de implementare. Ofertantul va asigura că, la momentul Go-Live, serviciile de suport și mentenanță pentru licențe sunt valabile pentru o perioadă de minimum 12 luni, acoperind perioada de garanție.

BNM subliniază că mediile de Dezvoltare și Testare sunt medii non-productive, iar așteptarea este ca licențierea propusă să fie adecvată acestui scop și să nu conducă la o creștere artificială a costurilor. În acest context: Ofertantul trebuie să propună un model de licențiere proporțional cu utilizarea non-producție (ex. număr redus de utilizatori, scop de dezvoltare/testare), evitând orice costuri nejustificate. Sunt acceptabile licențe dedicate mediilor de dezvoltare/testare, inclusiv modele pe bază de aranjamente specifice (ex. OTN sau echivalent), cu condiția respectării politicilor producătorului. Cerința de perpetuitate (CL.15) se aplică mediului de producție. Pentru mediile Dev/Test, ofertantul poate propune modele flexibile, adecvate duratei și scopului utilizării.

Pentru a evita o supradimensionare a licenței ofertate, BNM trebuie să dispună de dreptul de a diminua corespunzător numărul de licențe la Go-Live, dacă numărul de facto necesar este mai mic decât cel ofertat. Prin urmare, numărul de licențe perpetue este determinat la nivelul utilizării efective la Go-Live, nu la nivelul maxim ofertat. În situația în care ofertantul include o capacitate mai mare (ex. 100 utilizatori), iar la Go-Live sunt utilizați mai puțini (ex. 60), diferența nu se consideră automat licențiată și respectiv nici disponibilă fără costuri. Activarea ulterioară a unor licențe suplimentare va fi posibilă în baza condițiilor comerciale definite în ofertă (ex. prețuri unitare, mecanisme de extindere). Pentru componente licențiate pe bază de capacitate (ex. Oracle Database per procesor/core), se aplică același principiu. BNM va achita pentru capacitatea efectiv utilizată la Go-Live, iar orice extindere ulterioară se va realiza conform mecanismelor comerciale propuse de ofertant. Referitor la perioada de după Anul 6, TCO acoperă perioada inițială (Anii 1–6). După această perioadă, serviciile de suport și mentenanță vor face obiectul unor negocieri ulterioare, în funcție de condițiile de piață și politicile producătorilor.

Mecanismul la care se face referință a fost prevăzut pentru asigurarea predictibilității costurilor pe întreaga perioadă TCO, prin utilizarea unui model de licențiere bazat pe prețuri unitare transparente și predicitbile. În acest context: • Ofertantul trebuie să prezinte în ofertă un model de licențiere cu prețuri unitare clare, aplicabile pe întreaga perioadă TCO (6 ani), conform cerinței. • Pentru variații rezonabile ale numărului de licențe (în limita ±10% față de nivelul de referință), se va aplica același preț unitar atât pentru creșteri, cât și pentru reduceri, în conformitate cu cerința din TCO. • Protecția de preț ±10% se aplică în raport cu nivelul de referință stabilit (ex. la Go-Live) și este valabilă pe întreaga perioadă prevăzută de TCO. • Pentru variații care depășesc pragul de ±10%, ajustările se vor realiza în baza prețurilor unitare oferite de producătorul licențelor, însă cu menținerea unui mecanism transparent și predictibil. • În cazul în care același ofertant este desemnat câștigător pentru ambele loturi, licențele comune vor fi identificate și deduse o singură dată, pentru a evita dubla licențiere. • Identificarea licențelor comune se va baza pe propunerea ofertantului, fiind validată de către BNM în procesul de contractare, iar deducerea va fi reflectată direct în structura contractuală și financiară.

Ambele centre de date sunt deținute și operate de BNM (on-premise). Nu este prevăzută utilizarea unui centru de date comercial, sau a unor servicii de tip IaaS/PaaS. Arhitectura activ/pasiv a fost aleasă în mod deliberat, având în vedere obiectivele de optimizare a costurilor și a eficienței operaționale, în raport cu cerințele de reziliență și continuitate. Ofertanții trebuie să considere, la nivel de proiectare, o configurație realistă pentru un mediu activ/pasiv. Soluția propusă trebuie să fie flexibilă și adaptabilă la diferite scenarii de replicare (ex. sincronă sau asincronă) și să includă mecanisme adecvate pentru asigurarea RPO/RTO cerute. La moment, banda de transfer disponibilă pentru SAN este de 32 Gb între site-uri, pentru LAN 10 Gbps (care este în proces de modernizare la 100 Gbps), cu o latență sub 5ms, sufiecientă pentru replicarea sincronă a bazei de date. Chiar dacă, infrastructura BNM permite replicare sincronă, ofertanții sunt încurajați să propună arhitectura care oferă cel mai bun raport reziliență/cost, fără a presupune implicit utilizarea unor opțiuni mai costisitoare.

Soluția va fi implementată pe infrastructură on-premise, deținută și operată de BNM, în conformitate cu cerința CNF.54 (VMware pe hardware x86). Nu este avută în vedere, în cadrul acestui proiect, utilizarea unui cloud privat. În ceea ce privește Azure, acesta nu este prevăzut ca parte a arhitecturii CBS/ERP. Mediul Azure al BNM este complet separat de implementarea CBS/ERP. Cerința din CNF.43 privind „cel puțin PaaS” trebuie înțeleasă ca o cerință de aliniere arhitecturală la principii moderne de cloud computing (scalabilitate, modularitate, automatizare, portabilitate), nu ca o obligație ca soluția să ruleze efectiv pe o platformă PaaS.

BNM confirmă că responsabilitățile sunt distribuite între ofertant (proiectare arhitectură, dimensionare și cerințe) și BNM (procurare infrastructură, instalare și configurare până la nivel de SO), cu obiectivul comun de a asigura atingerea nivelurilor de performanță/reziliență stabilite în caietul de sarcini. În acest context: • Ofertantul este responsabil să furnizeze recomandări complete și corect dimensionate de infrastructură (hardware, resurse, configurații), astfel încât soluția să poată atinge cerințele de performanță și reziliență stabilite în caietul de sarcini, în condiții de utilizare normală. • BNM va avea în vedere aceste recomandări în procesul de achiziție/pregătire a infrastructurii. • Recomandările de dimensionare vor constitui referință tehnică în cadrul contractului și vor fi utilizate pentru validarea adecvării infrastructurii, fără a limita dreptul BNM de a ajusta configurațiile, cu condiția menținerii parametrilor minimi necesari și agreării prealabile a acestui fapt cu ofertantul selectat. • În situația în care infrastructura implementată se abate semnificativ de la recomandările propuse de ofertant fără ca acestea să fie coordonate de comun acord, iar acest fapt afectează în mod demonstrabil performanța/ reziliența, responsabilitatea pentru neîndeplinirea SLA-urilor va putea fi atribuită BNM. • BNM dispune de resurse virtualizate suficiente, care pot fi alocate progresiv pe parcursul proiectului, în funcție de necesitățile de implementare. Astfel, mediile necesare (dezvoltare, testare, pre-producție) pot fi asigurate în timp util, chiar și în cazul în care achiziția unor componente hardware suplimentare este în curs. • În ceea ce privește calendarul, achiziția infrastructurii va fi corelată cu etapele de implementare, pe baza recomandărilor ofertantului. • Eventualele întârzieri în livrarea hardware-ului vor avea impact limitat, fiind atenuate prin utilizarea resurselor virtualizate existente, iar acolo unde este necesar, planul de implementare va fi ajustat conform mecanismelor contractuale de gestionare a dependențelor.

Pentru asigurarea unui tratament egal al ofertanților și a comparabilității ofertelor, BNM solicită ca fiecare ofertant să includă în ofertă întregul necesar de licențe complementare pentru soluția propusă, independent de situația curentă a licențierii. Cu titlu informativ, pentru o mai bună înțelegere a contextului existent, comunicăm următoarele: • Licențele Oracle Database aferente sistemelor existente sunt deținute perpetuu de BNM. • BNM deține un contract activ de suport Oracle (Oracle Support Agreement) pentru licențele curente, acestea fiind licențiate în model Named User Plus (NUP). • În cadrul soluțiilor actuale sunt utilizate produsele Oracle Database și Oracle Forms. Totodată, menționăm că, în cazul în care, în cadrul etapei de analiză și design a soluției propuse, se va constata posibilitatea reutilizării anumitor licențe existente, BNM își rezervă dreptul de a solicita diminuarea corespunzătoare a cantității de licențe complementare necesare.

ESB-ul livrat în cadrul proiectului va deveni parte a platformei IT a BNM și va fi deținut și administrat de către BNM după Go-Live. Furnizorul CBS va asigura implementarea, configurarea și transferul de cunoștințe, precum și suportul necesar pe partea sa de responsabilitate (interfețele dezvoltate) în perioada de garanție și, ulterior, în baza unui acord de mentenanță (dacă va fi contractat). Referitor la existența unui middleware de integrare actual, BNM nu dispune de un astfel de sistem și respectiv nu prevede reutilizarea sau înlocuirea unei soluții existente specifice. Migrarea integrărilor existente (în măsura în care acestea sunt necesare pentru funcționarea noului sistem) va face parte din responsabilitatea furnizorului, însă doar pentru integrările relevante în perimetrul soluției ofertate CBS/ERP. Respectiv, nu se așteaptă ca furnizorul să preia sau să migreze în mod exhaustiv toate aplicațiile deținute, ci să implementeze doar integrările necesare conform perimetrului proiectului (a se vedea Anexa 10 pentru interfețele ce urmează a fi implementate).

Este de menționat că la această etapă a procedurii, nu pot fi furnizate specificații tehnice detaliate complete (ex. protocoale exacte, structuri de mesaje, definiții API) pentru toate integrările. În acest context este important de ținut cont cu privire la următoarele aspecte: • Anexa Nr. 10 oferă o viziune de nivel înalt asupra integrărilor necesare, inclusiv sistemele implicate și scopul acestora, constituind baza pentru dimensionarea inițială a soluției. • Suplimentar, în cadrul caietului de sarcini sunt incluse, în mod punctual, cerințe funcționale și tehnice care descriu mai detaliat tipurile de informații și fluxurile ce trebuie asigurate prin aceste integrări. • Specificațiile detaliate (inclusiv formate, protocoale, versiuni, documentație API) vor fi puse la dispoziția ofertantului câștigător în etapa de Analiză și Design, în vederea definirii și implementării integrărilor. • În ceea ce privește protocoalele și formatele de schimb de date, NBM are ca așteptare utilizarea unor standarde deschise și larg adoptate în industrie, cu prioritate pentru: o API-uri standardizate (ex. REST); o standarde specifice sectorului financiar (ex. ISO 20022); o alte protocoale consacrate, acolo unde este justificat. Suplimentar, menționăm că: - Swift: Pentru SWIFT modelul de conectare este SWIFT Alliance Gateway. Da, noul CBS se va conecta la infrastructura SWIFT existentă a BNM. - Bloomberg: Accesam date din Bloomberg prin intermediul protocoalelor SFTP si FIX (Produsele Bloomberg utilizate: SFTP: DATA LICENSE, AUCTIONS PLATFORM FIX: FIXED INCOME, FXGO.

BNM va furniza către CBS parametrii modelului ECL, aceștia putând fi introduși fie manual, fie prin încărcarea unor fișiere (ex. în format Excel). CBS va include un motor propriu de calcul pentru efectuarea calculelor ECL, în conformitate cu metodologia stabilită de BNM, rezultatele fiind generate lunar. În ceea ce privește evaluarea valorii juste, CBS nu necesită, în mod obligatoriu, dezvoltarea unui motor propriu complet de evaluare. CBS poate utiliza date de piață importate din platforme de tranzacționare (ex. Bloomberg), fie automat, fie manual, iar calculul valorii juste se realizează în cadrul CBS, în conformitate cu parametrii și metodologia stabilite de BNM.

Toate înregistrările per tranzacție se efectuează în valuta originală a instrumentului si echivalentul acestuia în MDL la cursul oficial, însă la generarea rapoartelor sa fie si in valuta EUR/USD. - Pentru metale prețioase urmează a fi utilizat prețul aurului stabilit de către BNM pentru ziua respectivă. Prețul este stabilit zilnic pentru un gram de aur fin exprimat în lei moldovenești - Pentru DST urmează a fi utilizat cursul oficial al leului moldovenesc fata de DST stabilit zilnic de către BNM. Cursul DSTMDL este în Lista valutelor străine fata de care BNM cotează leul moldovenesc. - In ziua in care primim ordinul de plata in „alte valute” (valuta in care BNM nu are cont corespondent) de la clientul BNM prin Client-Bank, acesta se importa in sistemul intern BNM si i se atribuie data valutei T+2 (conform cerințelor corespondentului unde BNM are cont multivalutar), respectiv data contabilizării care va fi identica cu data valutei. După autorizările corespunzătoare de către persoanele responsabile BNM, se creează si se exporta in SWIFT Alliance mesajul de tip pacs.008 in „alte valute” originala, care se expediază corespondentului in ziua primirii ordinului de plata. Urmare expedierii mesajului, de la banca corespondenta primim un mesaj de debitare (la moment MT900, ulterior camt.054) a contului cu suma echivalenta in EUR a sumei in „alte valute” expediata, respectiv cu data valutei corespunzătoare. La data valutei, in ordinul de plata din sistemul intern de evidenta, executorul introduce suma in EUR (din mesajul MT900 menționat), echivalentul căreia in MDL va fi egal cu echivalentul in MDL a sumei „alte valute” expediate la cursul oficial din data contabilizării. In cazul in care ordinul de plata in „alte valute” este a BNM-lui, ordinul de transfer se perfectează direct in SWIFT Alliance, conform condițiilor corespondentului descrise mai sus, iar ulterior la data contabilizării, in baza mesajului de debitare (MT900) se perfectează un document contabil in” alte valute” contra valuta contului corespondent prin care a fost efectuat ordinul de transfer respectiv. La moment, plățile in „alte valute” sunt doar in CHF, CAD si NOK.

- Instrumentele de politică monetară utilizate activ de BNM astăzi sunt operațiuni de emitere a certificatelor BNM și repo. În contextul schimbării situației pe piața monetară/deciziilor conducerii BNM/aderării la UE ar putea fi utilizate și celelalte instrumente care includ: tranzacţii reverse repo cu active eligibile; tranzacţii simple (vînzări și cumpărări definitive de VMS); acordare de credite garantate cu active eligibile; atragere de depozite la termen. - BNM nu a acordat ELA, dar instrument foarte similar. - Nu planificam sa avem intervenții umane la transmiterea din CBS in ADPS (CF.86) - Apeluri în marjă sunt efectuate de către Depozitarul Central Unic în conformitate cu art. 77 a Regulilor DCU în vigoare. Astfel apel în marjă se procesează în baza ordinului de plată emis de către DCU.

SAPI (ADPS) operează nativ în formatul ISO 20022 MX, nu este necesara conversia din MT in MX.

La moment BNM deservește cumulativ din numele RM 32 tranșe/facilități de împrumuturi acordate de FMI, după cum urmează: EFF – 14 tranșe, dintre care 6 partajate între BNM și MF și 8 exclusiv contractate de MF; ECF – 14 tranșe, dintre care 2 partajate între BNM și MF și 12 exclusiv contractate de MF; RSF – 3 tranșe, contractate de MF RCF – un împrumut activ contractat de MF. Cursul de schimb DST vs Valuta FX este un curs oficial, publicat zilnic de FMI și disponibil publicului. Conform normei standard a FMI în cadrul tranzacțiilor de conversie (DST vs Valuta) este utilizat cursul din T-2 de la data valutei operațiunii FX. Toate tipurile de inregistrari interne a mesajelor SWIFT intrari/iesiri presupun interventie manuala prin autorizare umana (câteva nivele, minim 2) inclusiv procesarea acestui tip de operațiune, principiu care urmează a fi aplicat și ulterior.

Confirmăm că Bloomberg rămâne platforma de tranzacționare pentru gestionarea rezervelor valutare și generarea tichetelor, în timp ce CBS va asigura decontarea, contabilitatea, evidența și capacitatea de încărcare automată a tichetelor generate de Bloomberg. De asemenea, confirmăm că BNM deține licența Bloomberg Data License, care autorizează extragerea datelor prin API. Pentru simulările pre-tranzacționare, acestea trebuie calculate utilizând motorul intern CBS. În prezent, NBM are 4 portofolii distincte de venit fix (Fixed Income) și un portofoliu de depozite la termen: 1. Portofoliu de venit fix administrat intern, raportat la un benchmark în euro 2. Portofoliu de venit fix administrat intern, raportat la un benchmark în USD 3. Portofoliu de venit fix administrat extern, raportat la un benchmark în USD 4. Portofoliu administrat intern, evaluat la cost amortizat, în EUR și USD 5. Portofoliu de depozite la termen în euro, USD și GBP În același timp, numărul portofoliilor de investiții sau monedele de denominare pot varia în timp.

BNM nu deține statut de participant SEPA Asociatia Bancilor din Moldova este NASO Nu există nici un hub național de transmitere/primire a mesajelor SEPA (aka infrastructură de decontare). Toate băncile sunt conectate individual, indirect. Nici o bancă nu este conectată direct la CSM. În dependență de intermediarul ales, CSM pot fi diferite. Moldova a fost admisă la 3 scheme: SCT, SCTinst, SDD. La moment băncile locale au aderat doar la SCT. BNM va utiliza una din aceste 3 scheme: SCT, SCTinst, SDD, care va fi decisa la etapa de analiza si design. SWIFT Alliance Gateway existent al BNM nu este configurat pentru rutarea SEPA.

- În conformitate cu cerințele BNM referitor la implementarea unui sistem modern și flexibil, așteptarea este ca interfețele să fie standardizate, pe cât posibil, prin API-uri, în linie cu bunele practici moderne de integrare. Soluția trebuie să fie flexibilă și să poată suporta atât integrare prin API-uri (implicit, inclusiv în timp real sau aproape în timp real), cât și schimburi de date de tip batch (ex. pe bază de fișiere), acolo unde este necesar. Deși anumite procese (ex. calcul salarial) pot avea o componentă periodică, există și evenimente operaționale frecvente (ex. acordare concedii, concedii medicale, alte modificări de statut), care necesită schimb de date mai frecvent, motiv pentru care API-urile sunt considerate mecanismul principal de integrare. Schimburile de tip batch pot fi utilizate complementar, acolo unde este justificat, însă nu reprezintă mecanismul implicit. Specificațiile detaliate ale interfeței sistemului de salarizare (formate, structuri de date, protocoale etc.) vor fi puse la dispoziția ofertantului câștigător în etapa de Analiză și Design. - Confirmăm că avantajul acordat salariaților sub forma subvenționării ratei dobînzii la creditele acordate sub nivelul pieței constituie facilitate impozabilă și este reglementată de art. 19 din Codul fiscal al RM. În acest sens: diferența dintre dobânda aplicată și dobânda de piață reprezintă venit impozabil pentru angajat. Acest avantaj urmează a fi determinat, evidențiat și raportat în scopuri fiscal conform legislației fiscale. Astfel, CBS trebuie să asigure: calculul automat al avantajului în natură aferent fiecărui angajat, în baza metodologiei stabilite; cu transmiterea informaţiei către sistemul de salarizare pentru a fi inclusă în baza impozabilă.

CBS trebuie să asigure posibilitatea înregistrării dispozițiilor generate în aplicația Deservirea Rezervelor Obligatorii (DRO) atât în mod automat (fără autorizare), cât și cu autorizare de către persoana desemnată. În prezent, la importul majorității dispozițiilor din DRO în Va-Bank este inclusă etapa de autorizare, iar în cazul unor dispoziții, importul se efectuează automat. În ceea ce privește specificațiile API, este de menționat că la această etapă a procedurii, nu pot fi furnizate specificații tehnice detaliate complete. Specificațiile detaliate (inclusiv formate, protocoale, versiuni, documentație API) vor fi puse la dispoziția ofertantului câștigător în etapa de Analiză și Design. În ceea ce privește SGED, menționăm următoarele: • Conform CI.32, ofertantul va analiza fluxurile existente (inclusiv cele implementate în SGED) pentru a defini o imagine end-to-end a proceselor. • Este important de menționat că utilizarea SGED pentru anumite fluxuri de proces reprezintă, în mare parte, o soluție de tip workaround, determinată de limitările sistemelor actuale. • Așteptarea BNM este ca, prin implementarea noului CBS/ERP, să se asigure consolidarea și automatizarea proceselor în cadrul sistemului principal, evitând fragmentarea acestora între mai multe platforme. • În acest sens, majoritatea fluxurilor de aprobare și procesare vor fi migrate și implementate în CBS/ERP, cu scopul de a asigura un nivel ridicat de automatizare și control integrat. • Pot exista excepții limitate, în special pentru fluxuri complexe sau transversale la nivel organizațional, unde menținerea în SGED (sau integrarea cu acesta) este justificată. • O listă detaliată a fluxurilor va fi pusă la dispoziția ofertantului câștigător în etapa de Analiză și Design, pentru definirea exactă a perimetrului.

1. Audit și aplicarea „dreptului de a fi uitat”: BNM confirmă că înregistrările de audit aferente tranzacțiilor financiare trebuie păstrate integral, inclusiv informațiile privind executorul și cei care au autorizat, pentru a asigura valoarea probatorie și conformitatea cu cerințele legale și de audit. În acest sens, cerințele privind „dreptul de a fi uitat” nu se aplică asupra înregistrărilor de audit ale tranzacțiilor financiare, în măsura în care acestea sunt necesare pentru respectarea obligațiilor legale. Totodată, trebuie avut în vedere că BNM, în mod obișnuit, nu desfășoară relații tranzacționale directe cu persoane fizice, astfel încât aplicabilitatea practică a acestui drept este extrem de limitată. Respectiv, anonimizarea/pseudonimizarea se va aplica, după caz, datelor cu caracter personal non-tranzacționale (ex. date de contact, anumite date operaționale auxiliare), în conformitate cu cadrul legal aplicabil. 2. Migrarea Datelor Așteptarea BNM este ca soluția să asigure continuitatea operațională și comparabilitatea datelor în perioada de tranziție. În acest context: • Se așteaptă ca toate datele master (ex. entități, conturi, nomenclatoare) și tranzacțiile active, împreună cu istoricul aferent acestora, să fie migrate integral în noul CBS/ERP. • Suplimentar, se prevede migrarea unei perioade relevante de date istorice, necesară pentru raportare, reconciliere și comparabilitate în perioada post Go-Live. • Pentru restul datelor istorice, nu se impune migrarea integrală în noul sistem. Acestea pot rămâne disponibile în sistemele existente, care vor fi menținute de către BNM în scopuri de raportare și consultare. • Strategia detaliată de migrare (volum, perioade, mecanisme tehnice, arhivare) va fi definită și agreată de comun acord între părți în etapa de Analiză și Design, în funcție de complexitate, riscuri și constrângeri operaționale.

Reieșind din faptul că aspectele legate de strategia de Go-Live (ex. big bang, rularea paralelă, mecanismele de rollback etc.) pot avea un impact major asupra succesului implementării, cerințele din caietul de sarcini prevăd ca ofertantul, reieșind din expertiza și experiența sa, să propună o viziune cu privire la aceste aspecte. Astfel, BNM nu impune o abordare predefinită pentru aceste elemente, însă se așteaptă ca abordările propuse să fie justificate din perspectiva reducerii riscurilor operaționale și a continuității activității. Deciziile finale privind strategia de Go-Live, rularea paralelă, criteriile de rollback, scenariile de testare și calendarul de implementare vor fi stabilite de comun acord în etapa de planificare detaliată, pe baza propunerii ofertantului, constrângerilor operaționale ale BNM, analizei detaliate a riscurilor și dependențelor, precum și a altor elemente relevante. Toate aceste aspecte vor fi analizate și agreate în mod colaborativ, cu implicarea tuturor părților relevante, astfel încât soluția finală să reflecte un echilibru optim între risc, cost și complexitate operațională. Referitor la testarea performanței (CNF.88): • scenariile de test, profilurile de utilizare și nivelurile de concurență vor fi definite și agreate în etapa de Analiză și Design, conform cerințelor din caietul de sarcini; • pentru testele de performanță, este considerată adecvată utilizarea seturilor de date sintetice, care pot simula volumele și tiparele reale de utilizare; • ofertantul va pune la dispoziție instrumentele și expertiza necesare pentru generarea acestor seturi de date, inclusiv pentru definirea scenariilor de test relevante; • BNM va contribui, acolo unde este necesar, cu informații privind profilurile de utilizare și volumele operaționale, pentru a asigura relevanța testelor.

Cu privire la solicitarea de extindere a termenului limită de depunere a ofertelor, vă informăm că aceasta va fi analizată de către Grupul de lucru pentru achiziții al BNM, ținând cont de complexitatea proiectului, de necesitatea asigurării principiului concurenței, precum și de respectarea cadrului legal aplicabil. În cazul în care vor fi operate modificări ale termenului limită de depunere a ofertelor, acestea vor fi comunicate tuturor operatorilor economici prin intermediul platformei MTender, în condiții de transparență și tratament egal.

În conformitate cu prevederile documentației de atribuire, și anume Anunțul de participare și Anexa nr. 8 – „Formularul cerințelor de calificare”, Ofertantul nu este limitat în a propune aceeași echipă de proiect pentru implementarea soluțiilor informatice aferente ambelor loturi. Acest lucru este permis cu condiția respectării tuturor cerințelor referitoare la numărul de experți-cheie și la criteriile de calificare ale acestora, precum și a asigurării respectării parametrilor de timp și calitate solicitați prin documentația de atribuire și oferta depusă.

Oferta depusă va cuprinde în mod obligatoriu cele 6 documente enumerate în Anunțul de participare și anume: Specificația de preț, Specificație tehnică, formularul DUAE (în cazul unei asocieri, va fi depus formularul DUAE pentru fiecare membru), Garanția pentru ofertă (scrisoarea de garanție bancară sau dova transferului prin SWIFT), Detalierea ofertei financiare pentru serviciile de implementare (Anexa nr. 3 la Caietul de sarcini), Costurile totale de deținere TCO (Anexa nr.4 la Caietul de sarcini). Totodată, în conformitate cu art.65 alin.(4) din Legea privind achizițiile publice nr.131 din 03.07.2015, prezentarea ofertei presupune depunerea într-un set comun, în mod obligatoriu, a propunerii tehnice (Specificația tehnică), propunerii financiare (Specificația de preț), formularul DUAE și garanției pentru ofertă la data deschiderii ofertei. Datorită caracterului public al procedurii de achiziție, formularele (Specifcații tehnice, Specificații de preț, Formularul DUAE și garanția pentru ofertă) își vor păstra obligatoriu caracterul public și nu poate fi clasificat ca secret comercial sau informație confidențială. Orice nerespectare a prevederilor de mai sus determină descalificarea ofertei. În cazul în care, celelalte două documente obligatorii aferente ofertei, precum Detalierea ofertei financiare pentru serviciile de implementare, Costurile totale de deținere (TCO), documentele de calificare și selecție dacă conțin informații confidențiale și/sau sunt atribuite la secretul comercial, în vederea protejării proprietății intelectuale și/sau a datelor cu caracter personal, în vederea respectării art.17 alin (2) din Legea nr.131/2015, se vor încărca în sistemul MTender ca fișiere parolate. Ulterior expirării termenului limită de depunere a ofertelor, Ofertantul, va transmite printr-un email parola către autoritatea contractantă, la adresa: To: achizitii.contracte@bnm.md.