Servicii de implementare a soluțiilor informatice de operaţiuni bancare și de gestionare a resurselor corporative (licențe, servicii de implementare și servicii de garanție) - REPETAT
suma planificată 79,998,333.33 MDL
| Lot | Valoare | CPV | Titlu achiziției | Cantitate | Livrare |
|---|---|---|---|---|---|
| Servicii de implementare a soluției informatice de operațiuni bancare (licențe, servicii de implementare și servicii de garanție) | 57,079,166.67 MDL | 72200000-7 | Servicii de garanţie (mentenanţă şi suport) aferente soluției informatice de operațiuni bancare (CBS) | 12 Bucata |
17.06.2026 - 31.12.2026 bd. Grigore Vieru, 1 |
| 72200000-7 | Licenţe aferente soluției informatice de operaţiuni bancare (CBS), cu 1 an de suport de la producător inclus | 1 Bucata | |||
| 72200000-7 | Licenţe complementare pentru rularea CBS (cu excepţia licenţelor pentru sistemele de operare), cu 1 an de suport standard de la producător inclus | 1 Bucata | |||
| 72200000-7 | Servicii de implementare ale soluției informatice de operațiuni bancare (CBS) | 1 Bucata | |||
| 72200000-7 | Servicii de instruire aferente soluției informatice de operațiuni bancare (CBS) | 1 Bucata | |||
| 72200000-7 | Servicii de integrare** | 1 Bucata | |||
| 72200000-7 | Servicii privind dezvoltări suplimentare și solicitări de schimbare | 2000 Bucata | |||
| Servicii de implementare a soluției informatice de gestionare a resurselor corporative (licențe, servicii de implementare și servicii de garanție) | 22,919,166.66 MDL | 72200000-7 | Licenţe aferente soluției informatice de gestionare a resurselor corporative (ERP), cu 1 an de suport de la producător inclus | 1 Bucata |
17.06.2026 - 31.12.2026 bd. Grigore Vieru, 1 |
| 72200000-7 | Licenţe complementare pentru rularea ERP (cu excepţia licenţelor pentru sistemele de operare), cu 1 an de suport standard de la producător inclus | 1 Bucata | |||
| 72200000-7 | Servicii de implementare ale soluției informatice de gestionare a resurselor corporative (ERP) | 1 Bucata | |||
| 72200000-7 | Servicii de instruire aferente soluției informatice de gestionare a resurselor corporative (ERP) | 1 Bucata | |||
| 72200000-7 | Servicii de integrare** | 1 Bucata | |||
| 72200000-7 | Servicii de garanţie (mentenanţă şi suport), aferente soluției informatice de gestionare a resurselor corporative (ERP) | 12 Bucata | |||
| 72200000-7 | Servicii privind dezvoltări suplimentare și solicitări de schimbare | 1000 Bucata |
Doua raspunsuri confirmate Q&A ridica nevoi de clarificare a perimetrului:
- Interfata RRS: Specificatia API a RRS (formate de date, tipuri de mesaje, definitii campuri) va fi pusa la dispozitie in perioada Q&A sau doar post-atribuire in faza de Analiza si Design? In plus, CBS trebuie sa inregistreze automat toate notele de instructiuni RRS (remunerare dobanda, debite de comisioane, amenzi pentru deficit) fara autorizare utilizator, sau fiecare instructiune trebuie autorizata de un ofiter BNM desemnat inainte de inregistrare?
- Absorbtia fluxurilor SGED: CI.32 impune furnizorului CBS sa revizuiasca si sa absoarba automatizarea proceselor implementata in prezent in SGED. Care fluxuri de procese de business legate de CBS sunt in prezent gazduite in SGED si nu in 'Va Bank'? BNM poate furniza chiar si o lista de nivel inalt pentru a permite ofertantilor sa evalueze perimetrul si efortul de absorbtie?
- Cine are autoritatea finala de a decide care fluxuri gazduite de SGED migreaza in noul CBS vs. raman in SGED - BNM singur sau necesita acordul mutual intre BNM si furnizor? Aceasta afecteaza modul in care furnizorul preteaza obligatia CI.32
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.
- Auditul pentru tranzactiile financiare trebuie sa identifice cine a initiat si autorizat fiecare tranzactie si nu pot fi practic anonimizate fara a le distruge valoarea probatorie legala. Cum se asteapta BNM ca cerinta 'dreptului de a fi uitat' sa fie aplicata in practica: anonimizarea este limitata la datele personale non-tranzactionale (ex: dosarele HR ale angajatilor, detaliile de contact ale clientilor), sau BNM se asteapta ca aceasta sa se extinda la inregistrarile pistei de audit ale tranzactiilor?
- Cerinta de date interogabile pe 5 ani a BNM (CNF.86) inseamna ca intreaga baza de date istorica de 20+ ani din 'Va Bank' trebuie migrata in noul CBS si sa ramana interogabila prin noua interfata, sau este acceptabila migrarea doar a ultimilor 5 ani (cu datele mai vechi intr-o arhiva separata)?
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.
Specificatiile permit ofertantului sa propuna strategia de go-live. CI.5 indica faptul ca in perioada de tranzitie, soldurile pot trebui preluate din 'Va Bank'. Va rugam sa clarificati:
- BNM are o preferinta intre Go-Live de tip big-bang (toate modulele simultan) si Go-Live fazat (pe modul sau arie functionala)? Pentru o banca centrala, profilul de risc al acestor doua abordari este foarte diferit.
- BNM va solicita o perioada de rulare paralela (ambele sisteme vechi si noi operand simultan cu reconciliere zilnica)? Daca da, care este durata minima asteptata de rulare paralela?
- CP.52 impune un plan de rollback. Care sunt conditiile de declansare a rollback-ului definite de BNM (ex: numarul si severitatea defectelor deschise) si care este timpul maxim tolerabil pentru revenirea la 'Va Bank' daca un esec la Go-Live impune rollback?
- Exista o fereastra preferata de Go-Live care sa evite ciclul de raportare financiara IFRS de sfarsit de an al BNM (de obicei T4)? Un Go-Live aproape de sfarsitul anului ar impune rularea primei inchideri IFRS pe un sistem nou.
- Conformitatea performantei CNF.88 (≤2 secunde pentru 95% din tranzactii) trebuie validata prin teste convenite intre parti. BNM va defini scenariile de test si profilurile de concurenta in cursul Analizei si Designului si vor fi furnizate date de test reprezentative pentru volumele efective ale BNM pentru validarea performantei?
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.
Referitor la complexitatea proiectului si a cerintelor exprimate prin caietul de sarcini, in vederea pregatirii unei oferte competitive si avantajoase pentru Autoritatea Contractanta, va rugam sa acceptati decalarea termenului de depunere cu minim10 zile lucratoare.
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.
1. Considering that the Payroll system will remain separate, what level of HR functionality is expected within the Lot II ERP? Should this include a full HR module (e.g., employee master data, leave management, time tracking), or only a minimal employee data repository sufficient to support integration with CBS-Payroll?
2. Is the existing Buget@ KP application intended to be fully replaced by the ERP procurement module, or will it remain in use alongside the ERP, requiring system integration?
3. For auxiliary services such as canteen management, rest house, and transport services (CF.31b–c), should these be managed directly within the ERP, or will they continue to operate in separate systems interfaced with ERP for financial accounting purposes?
4. Is the ERP procurement module expected to natively enforce Moldovan public procurement regulations (Law 131/2015), including thresholds and procedures, or will compliance continue to be handled externally via Buget@ KP or the national M-Tender platform?
5. Upon creation of a purchase order, should the ERP reserve (commit) the budget to prevent overcommitment (i.e., support commitment accounting)? Additionally, does NBM currently apply commitment accounting, or is budget execution tracked solely on a cash basis?
6. Should all three budget categories (Fixed Administrative, Internal Management, Monetary Policy Operations) be managed concurrently within the ERP using distinct workflows and access controls, or within a unified structure differentiated by analytical dimensions?
7. Does NBM apply IFRS 16 (Leases)? If so, should the ERP support full lease accounting capabilities, including right-of-use asset recognition, lease liability amortization, and related disclosures?
8. Are shared overhead costs (e.g., IT, facilities, HR) currently allocated across organizational units? If yes, what allocation bases are used (e.g., headcount, floor space, transaction volumes), and should these allocation rules be configurable by NBM administrators without vendor intervention?
9. What is the approximate number of cost centers and profit centers in the current management accounting structure? This will help determine the expected master data volume for the ERP’s managerial accounting module.
1. The Human Resources management module is out of scope of this project.
For Lot II (ERP) and CBS it is expected that the proposed solution has interfaces to import from the HR system only the necessary employee/user-related metadata required to support system functionality and integrations.
A full HR module (including functionalities such as leave management, time tracking, or comprehensive employee lifecycle management) is not required.
2. It is intended that the ERP system will fully replace the current Budget application.
3. A dedicated software solution (out of scope) is planned for canteen management, with simplified integration into the ERP system. The management of rest house and transport services is expected to be handled within the ERP system, to the extent supported by its native functionalities in a simplify manner (described in the RFP). NBM has a limit number of transport units (up to 15).
4. The procurement process will continue to be conducted through the M-Tender platform in accordance with public procurement regulations. Within the ERP system, it is planned to support the preparation and monitoring of the procurement plan, ensuring its alignment with the approved budget and tracking its execution.
5. Public procurement is carried out based on the approved budget, and therefore the system should support appropriate budget control and commitment mechanisms.
The administrative operating expenditure budget is prepared and executed on an accrual basis, and the ERP should support commitment accounting for this category.
At the same time, the administrative investment budget for long-term assets is executed on a cash basis, and the ERP should be able to accommodate this approach accordingly.
6. All budget categories should ideally be:
- Managed within a unified ERP structure,
- Differentiated using analytical dimensions,
- With distinct workflows and access controls applied as needed.
This approach ensures flexibility and scalability while avoiding system fragmentation.
7. Yes, NBM applies IFRS 16 Leases, and the solution should support full lease accounting in respect of the provisions of IFRS 16, including the right-of-use asset recognition, lease liability and interest amortization, as well as subsequent modifications to lease contracts. However, the NBM has few number of ongoing lease contracts.
8. Yes, shared overhead costs are intended to be allocated across organizational units.
There is currently no finalized cost accounting process in place. The approach will depend on the capabilities of the selected system, provided that it supports managerial cost reporting and allocation of shared costs.
Allocation keys and related rules will be defined during the design and configuration phase. The solution should allow NBM administrators to configure and adjust allocation rules without vendor intervention, using the standard functionalities of the selected module.
9. The approximate number of cost centers and profit centers is currently under determination. This information will be defined and confirmed during the analysis and design phase of the project.
At present, NBM consists of 26 subdivisions, structured across multiple organizational units, with over 30 operational processes.
Vă rugăm să confirmați ca, în vederea asigurării eficienței procesului de implementare și a optimizării timpilor aferenți transferului de cunoștințe, poate fi propusă aceeași echipă de implementare pentru ambele loturi.
Î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ă.
Vă rugăm să confirmați ca documentele aferente ofertei financiare, ofertei tehnice, echipei de implementare și experienței similare pot fi încărcate în platforma de ofertare în format parolat, urmând ca parola să fie comunicată Autorității Contractante prin e-mail.
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.