Achiziție - Platforma de Management a Pieței de energie cu servicii de implementare

Avand in vedere costul de deservire al platformei pe 3 ani, va rugam sa clarificati:

1. Ce activitati sunt incluse in perioada de deservire gratuita de 1 an.
2. Ce nivel de suport este asteptat in aceasta perioada (SLA).
3. Daca activitatile de suport si mentenanta pot influenta receptia finala a platformei.

... afișează tot conținutul

1. Menținerea funcționalității sitemului la parametrii din caietul de sarcini
2. Nivelul 3 de suport, cu posibilitatea în cazuri critice de urgentare
3. Nu vor influența

... afișează tot conținutul

Could the deadline for the proposal be postponed to 13.2.? This will allow more precise proposal based on the specification available from Moldelectrica.

... afișează tot conținutul

The deadline for the proposal is changed

... afișează tot conținutul

Is it required that system is installed on-premise? Or is it also possible to provide Software as a service? Is it possible that the solution is deployed to cloud environment (such as MS Azure) due to security reasons, as cloud might offer more secure environment?

... afișează tot conținutul

The system should be installed on-premise. SaaS is not acceptable.

... afișează tot conținutul

If we decide to submit the proposal on behalf of Consortium of 2 companies, is it OK if the registration on the portal is done for one of them, and in the proposal it is clearly stated this is submitted by a consortium?

Is it possible that some of the Mandatory requirements (such as Revenue per 3 years of the bidder, References, etc) is fulfilled by a third party, which capacity does bidder rely on? In such case, is it OK if the bidder states that it relies on the capacity of third party and submits the bid under its own bidder account?

... afișează tot conținutul

It is possible to submit from a Consortium leader account the bid. The documents should prove the Consortium consititution and responsabilities within Consortium. The 3rd party that is fulfilling the conditions should be part of consortium to fulfill the conditions. The account from which the submittal is done does not matter. The JVCA must satisfy the following minimum qualification requirements:
(a) The JVCA must satisfy collectively all the qualification criteria, for which
purpose the relevant figures for each of the partners shall be added to arrive at the joint venture's total capacity.
(b) Each partner shall meet not less than 50 percent of all the qualifying criteria for the turnover and the availability of the financial means as per the criteria specified under general experience and financial position.
Each partner shall satisfy the requirements with regard to the soundness of the financial position specified above.
(c) The lead partner of the JVCA shall demonstrate that he acted as a main contractor and
supplier on project(s) of similar magnitude.

... afișează tot conținutul

One of the evaluation criteria is "open-source SW". How do you define open source software? Does Moldelectrica plan to re-sell the software procured (which would fulfill the general definition of open-source SW?) Or is the goal to receive the source codes for the customisations of standard product prepared for Moldelectrica? In case we can hand over such source codes - does it fulfill your understanding of open source? Can you elaborate this topic?

... afișează tot conținutul

Moldelectrica does not plan to resell the product. The goal is to receive the source code of the system for some inhouse customizations if required.

... afișează tot conținutul

Would you be able to define contract for the delivery and maintenance and support? It may influence the delivery or the pricing. Especially the definition of SLAs, penalties, liabilities etc.

... afișează tot conținutul

Generally Level 3 SLA is required. But in case of complete system failure the posibility to solve the issue fast

... afișează tot conținutul

The specification refers to different sets of environments to be provided and supported by the Contractor.
- In Section 0.3 Contractor, it is stated that Production, Test, and Disaster Recovery sites are encompassed by this procurement.
- In Section 2.1 System-level requirements, it is stated that, in addition to the Production System, a Development and Testing System replicating the Production System with its own infrastructure shall be provided.

Moreover, The documentation specifies an expectation of two sites for the environments (Production), namely a Main site and a Disaster Recovery (DR) site. As part of our proposed technical solution, we would like to consider an alternative architecture based on an Active–Active deployment across three geographically separated locations, consisting of two primary nodes and an additional arbiter node.
Could you please confirm whether such an architecture would be acceptable within the scope of the tender requirements, provided that it fully satisfies (or exceeds) the stated availability, resilience, and disaster recovery objectives ? Are there any possibility to deploy application into 3 geographically separated locations for higher availability of future MMS system ? ​

Related to this, Could you please also confirm whether it is permissible to host the DEV environment at the contractor’s premises or within the contractor’s infrastructure, rather than at the premises of the contracting authority, provided that all security, confidentiality, access control, and compliance requirements specified in the tender documentation are fully met? ​

Could you please confirm the complete and definitive list of environments to be provided under the contract (e.g. Production, Test, Disaster Recovery, etc.)? This clarification is important for proper sizing and cost estimation of the MMS solution.

... afișează tot conținutul

Generally the requirement is based on Active/Passive site. The disaster recovery is based on back-up recovery of the system in case of complete failure. The test enviroment does not need any redunduse and should have a minimal setup. Therefore we do not consider necesarry to deploy it outside the company.

... afișează tot conținutul

Could you please clarify whether the MMS solution is expected:
- only to generate billing data and export it to external financial systems, or
- to generate the actual invoices (including invoice documents) within the MMS?

... afișează tot conținutul

Generate billing data and export it to external financial systems

... afișează tot conținutul

From the specification, it appears that the requirements include multiple processes that are not yet applicable to the Moldovan energy market, such as integration with JAO, MARI, and PICASSO platforms, as well as the application of flow-based methodology.
Given that:
a) such mechanisms are still evolving at the European level,
b) Moldova currently does not have access to these platforms, and
c) meaningful testing would not be possible during the 12-month MMS implementation period,
we believe that implementing, configuring, and testing these processes at this stage may not be an efficient use of budget and effort, and would likely require additional changes once Moldova is actually ready to join these platforms.
Would you consider reshaping these requirements so that the MMS solution is architecturally ready to support such integrations in the future, without requiring their full implementation and testing within the current project scope?

... afișează tot conținutul

The full implementation and testing is not part of Project scope, the system should have the necesarry capabilty and tools to be integrated at a later stage. Also the ncesessary documentation describing these modules should be provided

... afișează tot conținutul

The specification states that data should be presented in different time zones. However, several core processes - particularly scheduling and settlement - are based on daily or monthly periods.
Could you please clarify which time zone Moldelectrica intends to use to define the boundaries of a “day” and a “month” within the MMS? If different time zones are to be applied for different processes, we would appreciate it if you could specify the relevant processes and the corresponding time zones for each.
This clarification will help ensure consistent implementation and avoid ambiguities in period-based calculations.

... afișează tot conținutul

All internal (scheduling, settlement, …) processes are performed in local time. All external (scheduling, FSKAR, acounting...) processes are performed in CET/CEST timezone. One day for local processes is 24 hour in local time, for external processes 24 ours in CET/CEST time zone. For the presentation (UI,export,...) purpose the expectation is tha MMS should allow to change between local (EET), CET/CEST,UTC. As of database the data could be structured in one timezone (eg. UTC or other) and the procesess should be taged with adequate timezone and the posibility to visualize/export in different timezones.

... afișează tot conținutul

Could you please clarify whether the market schedules resulting from the Day-Ahead and Intraday markets will be provided to the MMS:
- exclusively by the Market Operator, or
- by both the Market Operator and market participants, with subsequent matching performed within the MMS?

... afișează tot conținutul

The schedules will be provided by both Market Operator and Market participants with subsequent matching performed by MMS. Market operator is one participant (granted with some special requirements related to schedule validations) from the MMS point of view. The DAM and IDM transactions shall be validated by MMS based on nominations provided by Market operator and market participants.

... afișează tot conținutul

Active Directory / LDAP Provisioning Scope
The documentation states that an Active Directory (AD) central server using LDAP shall be hosted by the MMS for user authentication. Could you please clarify whether this requirement implies that the Contractor is expected to deliver and operate a dedicated AD/LDAP service as part of the solution, or whether integration with an existing directory service provided by the contracting authority would be acceptable, provided that all functional and security requirements are fully met ? ​

Authentication Mechanisms, SSO, and Second Factor
The documentation refers to SSO authentication, LDAP / AD secure authentication, and mandatory two-factor authentication (2FA). Given that the target system is web-based, could you please clarify whether the use of modern, web-oriented authentication mechanisms (e.g. federation or token-based SSO solutions backed by AD) is acceptable in place of, or in combination with, direct LDAP-based authentication, while still maintaining AD as the authoritative identity source ? ​

... afișează tot conținutul

The AD/LDAP would be used only for local users from the company. The use of modern mechanism are encouraged.

... afișează tot conținutul

The tender documentation specifies the delivery of on-premises hardware infrastructure, including servers, storage, network equipment, and associated warranties. In this context, could you please clarify the following:

Hardware Installation
Is the Contractor expected to perform the physical installation of the hardware (rack mounting, cabling, initial power-up) on the contracting authority’s premises, or will these activities be performed by the contracting authority with the Contractor providing guidance and supervision as required ? ​

Hardware Maintenance During Warranty Period
During the warranty and maintenance period, could you please clarify whether the Contractor is expected to provide on-site hardware maintenance and replacement activities, or whether such activities will be handled by the contracting authority (or a designated third party), with coordination from the Contractor ? ​

Physical Access to On-Premises Infrastructure
Given that the solution is on-premises and subject to physical security controls, could you please clarify the expected level of physical access for Contractor personnel to the hardware infrastructure (e.g. escorted access, pre-approved access lists, security clearance procedures) for installation, maintenance, and warranty-related activities ? ​

Responsibility Matrix for Delivered Infrastructure
Could you please clarify the expected responsibility matrix for the delivered infrastructure, in particular the allocation of responsibilities between the Contractor and the contracting authority for hardware operation, monitoring, incident handling, routine maintenance, and lifecycle management during the warranty and support period ? ​

... afișează tot conținutul

The installation will be done be the Contractor. The exchange of equipment based on warranty provided by the vendor can be done by Client.
The physical access to the site will be escorted. There is no specific requirement to the responsibility, the system should be monitored/maintened remotely during warranty period periodically by the Contractor. Durring support perioad it will be decided based on cost impact.

... afișează tot conținutul

The tender documentation specifies the number of workstations and monitor configurations; however, requirements for the remaining workstation components are not explicitly defined. In order to ensure full compliance, could you please clarify the expected scope and specifications for the workstations beyond the monitors, including but not limited to computing hardware characteristics (e.g. CPU, memory, storage), graphics capabilities to support multi-monitor configurations, operating system requirements, preinstalled software, and any security or hardening standards to be applied ? ​

Additionally, please clarify whether the workstations are expected to be based on standard enterprise-grade hardware and operating systems, and whether approval or alignment with the contracting authority’s existing workstation standards is required.

... afișează tot conținutul

The provided worksations should handle operating the platform. Therefore the sizing of this workstations remains at the Contractor responsibility. Standard enterprise-grade hardware and operating systems is acceptable.

... afișează tot conținutul

In raspunsul la clarificari ati precizat ca se iau in considerare doar contractele finalizate pana la data depunerii ofertei.

Dorim sa mentionam ca in practica proiectelor IT complexe exista frecvent situatii in care contractele includ, pe langa livrarea si implementarea sistemului, si servicii continue de mentenanta si suport (support & maintenance), ceea ce face ca durata contractuala sa continue chiar daca livrarea principala a sistemului a fost realizata si receptionata de beneficiar.

In aceste situatii, sistemul a fost deja implementat si acceptat, iar contractul continua exclusiv pentru servicii operationale ulterioare.

Va rugam sa confirmati ca astfel de contracte pot fi considerate experienta similara eligibila, cu conditia prezentarii documentelor de receptie / acceptanta pentru livrarea sistemului sau a componentelor principale, chiar daca contractul continua pentru servicii de mentenanta sau suport.

... afișează tot conținutul

Contracte in care livrarea principală a sistemului a fost realizată și acceptată, chiar dacă se află în perioada de mentenanță ulterioară vor fi acceptate

... afișează tot conținutul

In raspunsurile la clarificari ati mentionat ca punctajul aferent factorului „Source-code (SC)” se acorda atunci cand codul sistemului este open-source.

Dorim sa intelegem mai clar intentia acestei cerinte, respectiv asigurarea independentei beneficiarului fata de furnizor si posibilitatea de a modifica sau adapta sistemul in viitor.

In acest sens, va rugam sa confirmati daca se considera ca cerinta este indeplinita in situatia in care:

– beneficiarul primeste integral implementarea realizata pentru proiect (fluxuri, configurari, logica aplicativa, servicii dezvoltate etc.);
– aceasta implementare poate fi modificata, extinsa sau adaptata independent de furnizor;
– arhitectura solutiei permite utilizarea unor tehnologii moderne (ex. microservicii, configurare declarativa, low-code sau alte mecanisme care permit adaptarea sistemului fara dependenta de furnizor);

chiar daca platforma tehnologica utilizata pentru executia acestei implementari este furnizata sub licenta comerciala perpetua standard si nu este modificata in cadrul proiectului.

Va rugam sa confirmati ca, in aceasta situatie, cerinta privind accesul la implementarea sistemului si independenta beneficiarului este considerata indeplinita.

... afișează tot conținutul

Confirmam

... afișează tot conținutul

In raspunsurile la clarificari ati mentionat ca informatiile privind volumetria datelor se regasesc in Caietul de sarcini.

Am analizat sectiunile relevante din Caietul de sarcini si am identificat informatii privind volumele actuale de date, insa nu am identificat o estimare explicita privind cresterea anuala a volumelor de date sau ipotezele de dimensionare pe termen lung.

Avand in vedere ca sistemul trebuie sa asigure retentia datelor pentru o perioada de minimum 10 ani, va rugam sa confirmati:

1. daca exista o estimare oficiala a cresterii anuale a volumelor de date care trebuie luata in calcul la dimensionarea solutiei;
2. daca valorile mentionate in Caietul de sarcini reprezinta doar situatia curenta sau includ deja o proiectie de crestere;
3. in lipsa unei estimari explicite, ce ipoteza minima de crestere ar trebui utilizata de ofertanti pentru dimensionarea infrastructurii.

... afișează tot conținutul

Valorile din caietul de sarcini iau in calcul proiectia de crestere

... afișează tot conținutul

In raspunsul la clarificari ati mentionat ca proiectul de contract va fi negociat cu ofertantul castigator, pe baza prevederilor din Anuntul de participare si Caietul de sarcini.

Avand in vedere complexitatea proiectului si necesitatea evaluarii corecte a riscurilor contractuale inainte de depunerea ofertelor, dorim sa mentionam ca anumite elemente contractuale pot avea un impact semnificativ asupra modului de structurare a ofertei (tehnice si financiare).

In acest context, va rugam sa puneti la dispozitia ofertantilor, anterior depunerii ofertelor, cel putin informatii de principiu privind urmatoarele aspecte:

– regimul penalitatilor aplicabile pentru intarzieri sau neconformitati;
– existenta sau inexistenta unor limitari ale raspunderii contractuale;
– mecanismul general de acceptanta si receptie a sistemului;
– conditiile principale de incetare a contractului.

Aceste informatii sunt necesare pentru ca ofertantii sa poata evalua corect riscurile si sa formuleze oferte comparabile si sustenabile.

... afișează tot conținutul

A se vedea modelul de contract încărcat

... afișează tot conținutul

In raspunsul la clarificari ati mentionat ca, in cazul participarii in asociere, fiecare membru al asocierii trebuie sa indeplineasca minimum 50% din criteriile economico-financiare.

Pentru evitarea oricaror interpretari diferite, va rugam sa confirmati daca acest prag de minimum 50% se refera strict la criteriile economico-financiare (ex. cifra de afaceri / capacitatea financiara) si nu se aplica altor cerinte din documentatia de atribuire.

... afișează tot conținutul

Confirmăm

... afișează tot conținutul

In raspunsul la clarificari ati mentionat ca ofertantul este responsabil pentru echipamentele de interconectare si protectie (ex. switch-uri, firewall-uri), iar conectarea se va face in core switch-urile beneficiarului prin interfete SFP 1G sau 10G.

Avand in vedere ca diagrama infrastructurii va fi furnizata doar ofertantului castigator, va rugam sa confirmati urmatoarele ipoteze minime de integrare care sa fie utilizate in mod unitar de catre toti ofertantii:

1. conectarea fiecarui rack la reteaua beneficiarului se realizeaza prin doua uplink-uri independente (cate unul in fiecare core switch);
2. integrarea se realizeaza la nivel de Layer 2 sau Layer 3 conform configuratiei standard a retelei beneficiarului;
3. nu exista cerinte suplimentare de segmentare, routing sau securitate care ar putea influenta dimensionarea echipamentelor ofertate.

Aceste clarificari sunt necesare pentru ca ofertantii sa dimensioneze corect echipamentele de interconectare si securitate.

... afișează tot conținutul

1. Se propune conectarea fiecarui rack cu căte un uplink la core switch, conexiunea între rack-uri pentru sistemul livrat trebuie să fie redundantă
2. Propunem ca conexiunea să fie realizată prin Layer 3
3. Sistemul e necesar sa fie protejat la granița de intrare în sistem (firewall). În caz că soluția propusă a ofertantului necesită segmentare interioară, este la discreția ofertantului să propună echipamentul necesar pentru realizarea acesteia.

... afișează tot conținutul