Website integrat cu sistemele informaționale
suma planificată 515,000.00 MDL
§5.2.1 cere o acuratețe minimă de recunoaștere a intenției de 85% „pe setul de testare”, iar §9.2
cere un containment rate ≥ 70% în UAT.
Întrebare: Va furniza SA „Energocom” setul de testare oficial pentru aceste praguri de acceptanță,
sau setul este propus de furnizor și validat comun în săptămâna 1–2? În al doilea caz, ce volum
Întrebări pentru runda de clarificări — SA „Energocom”
Das Soft Plus S.R.L. (CoRLab Tech) — IDNO 1019600011052 Pagina 2 din 3
minim de scenarii așteptați pentru un set considerat reprezentativ (propunem 150 scenarii/limbă ×
Setul de scenarii, de testare pentru evaluarea pragurilor de acceptanță va fi propus de furnizor și validat de beneficiar. Volumul minim obligatoriu este de 150 scenarii per limbă (RO, RU, EN), totodată beneficiarul își rezervă dreptul de a completa sau înlocui o parte din scenariile propuse de furnizor, fără ca aceasta să constituie o modificare a condițiilor contractuale. Setul final, agreat de ambele părți, constituie documentul de referință pentru criteriile de acceptanță prevăzute în §9.2.
§2.1 permite server dedicat sau cloud, în Republica Moldova sau în UE cu certificări adecvate.
Întrebare: Există o preferință a SA „Energocom” pentru: (a) hosting on-premises la sediul
Energocom; (b) MCloud (Republica Moldova); (c) cloud EU (AWS Frankfurt/Ireland, Azure West
Europe, GCP europe-west)? Cine acoperă costurile de hosting în anii 2 și ulteriori (după garanție)?
Beneficiarul va comunica furnizorului câștigător decizia privind tipul și localizarea infrastructurii de hosting în cadrul ședinței de kick-off, anterior demarării Livrabilului 4 (Săpt. 5 – 6). Costurile de hosting pe durata contractului (livrare + garanție) sunt suportate de beneficiar și nu se includ în oferta financiară. Ofertanții vor specifica în oferta tehnică cerințele minime de infrastructură necesare pentru funcționarea soluției propuse, inclusiv pentru modulul de chat și baza RAG. Costurile de hosting post – garanție nu fac obiectul prezentei achiziții.
§8.1 cere ca serviciul SMTP pentru emailuri din formulare să fie implementat prin Microsoft Graph
(„server SMTP care va utiliza Microsoft Graph pentru expedierea mesajelor”).
Întrebare: Confirmați că SA „Energocom” are deja un tenant Microsoft 365 / Entra ID activ și o cutie
poștală de serviciu (ex: noreply@energocom.md) pe care o veți pune la dispoziție furnizorului. Dacă
nu, acceptați ca alternativă un SMTP relay tradițional (SendGrid, Mailgun, Postmark) sau preferați
să procurați tenantul Microsoft 365 înainte de kick-off?
Cerințele privind serviciul de expediere a emailurilor din formulare sunt definite în §8.1 din caietul de sarcini. Ofertanții vor include în oferta tehnică soluția propusă pentru această integrare, cu justificarea conformității față de cerința menționată. Detaliile tehnice de acces necesare implementării vor fi comunicate furnizorului câștigător la kick-off.
§2.1 acceptă atât CMS open-source (WordPress 6.9+, Drupal 11+) cât și soluție custom cu acces
complet la codul-sursă.
Întrebare: Există o preferință a comisiei de evaluare pentru una dintre cele două abordări? În
particular, o soluție custom (ex. Strapi / Directus headless + Next.js/Nuxt) cu acces complet la codulsursă este considerată echivalentă cu o soluție WordPress sau Drupal din perspectiva conformității
cu §2.1?
Cerințele privind tipul platformei sunt definite în §2.1 din caietul de sarcini, care permite atât soluții CMS open-source cât și soluții custom, cu condiția accesului complet la codul sursă și a respectării tuturor cerințelor funcționale din Cap. 4. Comisia de evaluare nu acordă preferință niciuneia dintre abordările permise. Evaluarea ofertelor se va face exclusiv pe baza criteriilor declarate în §12.3.
Caietul de sarcini §5.5 menționează ca opțiuni: API extern (OpenAI GPT-4o / Anthropic Claude 3.5
/ Google Gemini / OpenRouter) SAU model local open-source justificat în ofertă. Pentru a putea
propune arhitectura și prețul corecte, vă rugăm să clarificați:
Cine asigură motorul LLM și costurile de inferență?
Dacă se preferă LLM open-source local (privacy maximă, suveranitate date), Are SA „Energocom” infrastructură GPU disponibilă?
Cerințele privind motorul AI sunt definite în §5.5 și §12.1 din caietul de sarcini. Ofertanții vor include în oferta tehnică arhitectura propusă pentru motorul LLM, cu justificarea alegerii (API extern sau model local), conform §12.1 pct. 2. Toate resursele necesare funcționării soluției propuse pe durata contractului, inclusiv perioada de garanție, vor fi reflectate în oferta financiară ca preț total fix, conform §12.2. Detaliile privind infrastructura disponibilă la beneficiar vor fi comunicate furnizorului câștigător în cadrul kick-off-ului.
§2.1 din Caietul de sarcini menționează „migrare sau configurare nouă” pentru domeniul
www.energocom.md.
Întrebare: Este așteptat ca furnizorul să migreze conținutul existent (pagini, comunicate, documente
PDF) de pe site-ul curent energocom.md? Dacă da, vă rugăm să indicați: (i) numărul aproximativ de
pagini și documente; (ii) dacă veți pune la dispoziție un export al conținutului existent
(CSV/XML/backup); (iii) dacă lista de redirecționări 301 este pregătită sau trebuie generată de
furnizor.
Furnizorul nu are obligația de a migra conținutul existent de pe site-ul actual energocom.md. Prezenta achiziție vizează dezvoltarea unui site web nou. Conținutul spre publicare va fi pus la dispoziție de beneficiar conform Cap. 7.1. Structurarea și încărcarea acestuia în CMS constituie obligația furnizorului conform Cap. 7.2. Cu privire la punctele specifice: (i) nu este aplicabil; (ii) nu este aplicabil; (iii) lista redirecționărilor 301 pentru URL-urile cu relevanță SEO va fi pusă la dispoziție de beneficiar. Furnizorul are obligația de a configura tehnic redirecționările 301 în CMS pe baza listei primite.
§7.1 din Caietul de sarcini menționează că textele paginilor statice, logotipul, brand-book-ul și
fotografiile instituționale sunt furnizate de beneficiar.
Întrebare: Confirmați că brand-book-ul actualizat al SA „Energocom” va fi disponibil furnizorului în
săptămâna 1 a proiectului. Dacă nu există un brand-book formalizat, acceptați ca furnizorul să
propună un refresh limitat al identității vizuale (păstrând logotipul și culorile corporative), validat de
echipa „Energocom”?
Cerințele privind identitatea vizuală și conținutul furnizat de beneficiar sunt definite exhaustiv în §2.2 și §7.1 din caietul de sarcini. Materialele necesare vor fi puse la dispoziția furnizorului câștigător conform calendarului agreat la kick-off, anterior demarării fazei de design grafic (de văzut livrabilele §10). Ofertanții vor include în oferta tehnică abordarea propusă pentru faza de design, cu respectarea cerințelor din §2.2.
Întrebarea 1:
Capitolele 1.3 și 15.1 prevăd că site-ul instituțional nu integrează funcționalități de autentificare sau date personale și că modulul de chat este destinat exclusiv vizitatorilor publici. Capitolul 5.7 descrie însă chat-ul ca funcționând în două moduri, inclusiv un mod autentificat în Cabinetul Consumatorului, cu acces la date despre client. Vă rugăm să confirmați care dintre variantele de mai jos reprezintă scopul efectiv al ofertei:
(a) Furnizorul livrează exclusiv chat-ul public (Cap. 5.1–5.6); modul autentificat din Cap. 5.7 este descris informativ și va fi implementat de furnizorul Cabinetului.
(b) Furnizorul livrează chat-ul public și o interfață/API documentată pentru integrarea ulterioară cu Cabinetul, fără a realiza integrarea efectivă.
(c) Furnizorul livrează ambele moduri, inclusiv integrarea cu Cabinetul Consumatorului.
Întrebarea 2:
Dacă răspunsul este (b) sau (c), vă rugăm să precizați: cine asigură specificațiile API ale Cabinetului, dacă aplicația Cabinet există sau urmează a fi dezvoltată în paralel, și calendarul de disponibilitate al acestor specificații.
Întrebarea 3:
În variantele (b) sau (c), confirmați dacă mecanismul SSO (recunoașterea automată a sesiunii din Cabinet de către chat) este responsabilitatea furnizorului site-ului public sau a furnizorului Cabinetului.
Conform condițiilor caietului de sarcini, modulul de chat este destinat exclusiv vizitatorilor publici, ceia ce presupune că Furnizorul livrează exclusiv chat-ul public (Cap. 5.1 – 5.6) iar modul autentificat din Cap. 5.7 este descris informativ și va fi implementat de furnizorul Cabinetului.