Sistem informațional pentru activitatea de furnizare a gazelor naturale

Perioada de actualizare

de la 16.09.2024 14:39
până la 07.10.2024 09:00

Propunerea ofertelor

de la 07.10.2024 09:00
până la 31.10.2024 07:00

au rămas 12 zile

Licitaţie

nu va fi folosită

Evaluare

Contract

Statut Propunerea ofertelor

Valoarea estimată fără TVA 52 600 000 MDL

Perioada clarificărilor: 16 sept 2024, 14:39 - 7 oct 2024, 9:00

Perioada de depunere a ofertelor: 7 oct 2024, 9:00 - 31 oct 2024, 7:00

Suport Tehnic pentru furnizori:

(+373) 79999801

Aceasta procedura se va desfășura fară licitație electronică. Oferta Dvs. este finală și trebuie să conțină toată lista de documente cerută de documentația de atribuire.

Descriere
Clarificări (36)

Sistem informațional pentru activitatea de furnizare a gazelor naturale

Documente

Informaţia despre solicitant

Denumirea

MOLDOVAGAZ S.A.

Codul fiscal/IDNO

1003600005148

Adresa

2005, MOLDOVA, mun.Chişinău, mun.Chişinău, Alexandr Puskin nr.64

Web site

---

Persoana de contact

Nume Prenume

Ana Vitiu

Telefonul de contact

022578730

E-mail

ana.vitiu@moldovagaz.md

Datele achizitiei

Data publicării

16 sept 2024, 14:08

Data ultimilor modificări

26 sept 2024, 17:15

Achizitii.md ID

21278443

MTender ID

ocds-b3wdp1-MD-1726484885053

CPV

48440000-4 - Pachete software de analiză financiară şi contabilitate

Tipul procedurii

Licitație deschisă

Criteriu de atribuire

Cel mai bun raport preț - calitate

Surse de finanțare

20229492

Lista loturilor

Lotul nr. 1 - Sistem informațional pentru activitatea de furnizare a gazelor naturale

Buget: 52600000.0 MDL

Activ

Treceți la lot

Documentele procedurii de achiziție

202409161425_Anunț de participare SI de furnizare gaze.pdf

Documentele la ofertă

Anunț de participare

16.09.24 14:39

202409161428_Documentatie de atribuire SI FG MG.docx

Documentele la ofertă

Documentația de atribuire

16.09.24 14:39

202409161428_Documentatie de atribuire SI FG MG.pdf

Documentele la ofertă

Documentația de atribuire

16.09.24 14:39

Anunț de participare SI de furnizare gaze.docx

Documentele la ofertă

Anunț de participare

16.09.24 15:06

CS SI activitate de furnizare gaz MG.pdf

Documentele la ofertă

Caiet de sarcini

16.09.24 15:06

CS SI activitatea de furnizare gaze MG_ro.docx

Documentele la ofertă

Caiet de sarcini RO

26.09.24 17:15

Data:

19 sept 2024, 10:08

Subiectul întrebării:

Dublare de anunt

Întrebare:

Am indentificat aproximativ acelasi caiet de sarcini si cu acelasi buget publicat de Chisinau Gaz. https://achizitii.md/en/public/tender/21279725/ Este o eroare, sau cum se explica aceasta?

Răspuns (20 sept 2024, 11:32):

Buna ziua, cu referire la clarificarea dvs vă comunicăm. Sunt doua achiziții diferite. SA ”Moldovagaz” va achiziționa Sistem informațional pentru activitatea de furnizare (vînzarea gazelor naturale către consumatori) a gazelor naturale, iar ”Chișinău-gaz” SRL va achiziționa Sistem informațional pentru activitatea de distribuție (transmiterea gazelor naturale prin rețelele de distribuție) a gazelor naturale. În contextul în care aceste sisteme vor interacționa pe diverse procese și vor necesita integrare profundă, sarcinile tehnice pe compartimentul “Cerințe nonfuncționale” sunt similare. Totodată compartimentul cu cerințe funcționale sunt specific fiecărei activități și sunt diferite. Referitor la bugete, sunt similare, deoarece complexitatea acestor sisteme sunt la fel similare.

Sistem informațional pentru activitatea de furnizare a gazelor naturale

Data:

25 sept 2024, 18:26

Subiectul întrebării:

Modalitate depunere oferte

Întrebare:

Buna ziua. Cu referire la: Entitatea contractantă RECOMANDĂ ofertanților să depună în sistemul electronic SIA RSAP (MTender), vă rugăm să specificați care este modul de depunere, deschidere și examinare a ofertelor recepționate în afara sistemului electronic SIA RSAP (MTender)?

Răspuns (26 sept 2024, 13:09):

Buna ziua. În temeiul legislației în vigoare și întru asigurarea transparenței și încrederea publicului față de companie în procesul de achiziție, SA ”Moldovagaz” utilizează serviciului guvernamental digital – SIA RSAP (MTender), unde fiecare clarificare/decizie de achiziție este publicată în mod transparent online în timp real, pentru toți participanții la procesul de achiziție asigurînd accesul egal pentru toți canditații/ofertanții interesați. În conformitatea cu Anunțul de participare - ofertele, cererile de participare și informațiile solicitate (documentație) este necesar de prezentat obligatoriul prin intermediul SIA RSAP (MTender), alt mod de prezentare a ofertelor nu se acceptă. Cu referire la pct. 15.10 ”Entitatea contractantă recomendă ofertanților să depună în sistemul electronic SIA RSAP (MTender), toate documentele solicitate în documentele de atribuire (inclusiv în anunțul de participare), la momentul depunerii ofertei”, iar examinarea ofertelor depuse se va efectua în baza documentelor depuse prin intermediul platformei electronice SIA RSAP (MTender).

Sistem informațional pentru activitatea de furnizare a gazelor naturale

Data:

25 sept 2024, 18:58

Subiectul întrebării:

Cerințe față de experiență

Întrebare:

În legătură cu cerința privind "Experiență dovedită de integrare cu sistemele guvernamentale moldovenești în cel puțin 3 proiecte în ultimii 5 ani. Informația se va prezenta în formă liberă", vă rugăm să precizați următoarele aspecte: - Care este numărul minim de sisteme guvernamentale moldovenești cu care s-au făcut integrări? - Ce se are în vedere prin sisteme guvernamentale moldovenești? - Orice sistem informatic guvernamental sau sisteme informatice specifice? Mulțumim.

Răspuns (26 sept 2024, 13:09):

Prin „sistem guvernamental moldovenesc” se înțelege orice sistem software/aplicație implementată la nivelul guvernului sau al unei organizații din sectorul public. Totuși, în cadrul acestei proceduri, vor fi analizate în mod specific sistemele care fac parte din ecosistemul guvernamental digital, deoarece acestea respectă standarde tehnice internaționale, iar informația despre experiența ofertanților privind integrările pot fi verificate cu ușurință. Astfel, ofertanții vor descrie experiența de integrare cu sistemele/platformele informatice din lista următoare, care reprezintă numărul minim de sisteme guvernamentale cu care este necesar să aibă experiență: • MCloud-platforma guvernamentala de cloud • MConect-platforma de interoperabilitate • MPay – serviciul de plată • MPass- serviciul de autentificare • MSign – serviciul de semnătura digitală • MNotify-serviciul de notificare • MPower-serviciul de autentificare • MDocs – depozitarul de documente • MDelivery-serviciul de livrare Număr minim de sisteme: 9 La fel opțional este binevenită experiența și cu următoarele sisteme • MLog- serviciul de jurnalizare • FOD – Front Office Digitization • MCabinet – cabinetul cetățeanului.

Sistem informațional pentru activitatea de furnizare a gazelor naturale

Data:

25 sept 2024, 18:58

Subiectul întrebării:

Cerințe față de experiență

Întrebare:

Răspuns (26 sept 2024, 13:12):

Vă rugăm să vizualitați răspunsul de mai sus.

Data:

26 sept 2024, 08:42

Subiectul întrebării:

Администрирование пользователей и контроль доступа

Întrebare:

• Допускается ли возможность назначать более чем одну группу прав доступа для пользователя? Например, пользователь может быть одновременно и Администратором, и Технологом? • В техническом задании указано, что в обязанности Администратора Системы входит мониторинг процесса функционирования ИС. Правильно ли мы понимаем, что тут подразумевается, например, мониторинг производительности ИС во время обработки запросов с последующим отображением статистики по времени обработки отправленного запроса (для своевременного выявления увеличения время отклика ИС и поиска причины возникшей проблемы)? • В техническом задании указано, что Администратор Системы должен иметь доступ к управлению интерфейсами взаимодействия с внешними и внутренними ИТ-системами. Не могли бы вы немного пояснить что именно подразумевается под этим требованием?

Răspuns (26 sept 2024, 13:13):

Да, допускается возможность назначать более чем одну группу прав доступа для пользователя.

Data:

26 sept 2024, 08:42

Subiectul întrebării:

Общие функциональные требования к системе

Întrebare:

• Не могли бы Вы пояснить что Вы подразумеваете функциональной возможностью копирования данных для дальнейшего использования? • Вы указываете о возможности настройка уведомлений или оповещений при изменении важных данных. Правильно ли мы понимаем, что тут подразумеваются не только уведомления, которые строго привязаны к каким-либо событиям в ИС, но и возможность отправлять дополнительные уведомления пользователям, например, Администратором Системы при необходимости?

Răspuns (26 sept 2024, 13:14):

В основном это сообщения потребителям, но есть и процессы, по которым нужно оповестить и внутренних пользователей.

Data:

26 sept 2024, 08:42

Subiectul întrebării:

Ведение справочников

Întrebare:

• Вы упоминаете, что справочники должны обновлять данные на основе Государственного Регистра через web-сервис. Должна ли запускаться процесс синхронизации, как только данные на стороне Государственного Регистра были изменены/обновлены? • В техническом задании указана необходимость наличия конструктора/редактора шаблонов документов, который использует справочник «Шаблоны документов». Подразумевается ли здесь полноценный конструктор шаблонов документов, как например Fast Reports (или что-то подобное с аналогичным функционалом)? • Может ли пользователь создавать новые справочники, помимо тех, которые должны обязательно существовать в соответствии с техническим заданием? • Если пользователю необходимо удалить какую-либо запись из выбранного справочника, при этом эта запись использована, например, в карточке потребителя, и является обязательным атрибутом, то как быть в такой ситуации? Запрещать удаление в принципе? Или реализовать логику, согласно которой можно назначить иную запись из справочника для всех потребителей, который попадают под эффект удаления записи?

Răspuns (26 sept 2024, 13:15):

Вы упоминаете, что справочники должны обновлять данные на основе Государственного Регистра через web-сервис. Должна ли запускаться процесс синхронизации, как только данные на стороне Государственного Регистра были изменены/обновлены? Нет, данные должны обновляется по запросу со стороны Заказчика (планировщик и/или ручной режим) В техническом задании указана необходимость наличия конструктора/редактора шаблонов документов, который использует справочник «Шаблоны документов». Подразумевается ли здесь полноценный конструктор шаблонов документов, как например Fast Reports (или что-то подобное с аналогичным функционалом)? Наличие конструктора/редактора шаблонов документов обязательно, а реализация может быть в как Fast Report и даже использовать MS Word как редактор шаблонов. Детализация будет на этапе внедрения. • Может ли пользователь создавать новые справочники, помимо тех, которые должны обязательно существовать в соответствии с техническим заданием? Да • Если пользователю необходимо удалить какую-либо запись из выбранного справочника, при этом эта запись использована, например, в карточке потребителя, и является обязательным атрибутом, то как быть в такой ситуации? Запрещать удаление в принципе? Или реализовать логику, согласно которой можно назначить иную запись из справочника для всех потребителей, который попадают под эффект удаления записи? Данные из справочников будут служить для заполнения карточек объектов, а после сохранения объекта связь теряется. Тем не менее случаи будут разные и для каждого будут свои правила, которые обседаться на этапе разработки.

Data:

26 sept 2024, 08:43

Subiectul întrebării:

Учет потребителей

Întrebare:

• В техническом задании указана возможность интеграции с внешними источниками для автоматического обновления данных потребителей. Здесь подразумевается Государственный Регистр или иная внешняя ИС? • Согласно техническому заданию, карточка потребителя должна содержать данные о репутации потребителя, и обновление репутации происходит в соответствии с бизнес-правилами. Это требование имеет ссылку на отсутствующий раздел в ТЗ. Не могли бы предоставить немного деталей о механизмах расчета репутации потребителей?

Răspuns (26 sept 2024, 14:49):

В зависимости что конкретно вы подразумеваете под данным вопросом, у нас предусмотрено и то, и то.

Data:

26 sept 2024, 08:43

Subiectul întrebării:

Плановые объемы

Întrebare:

• Вы указываете о необходимости наличия визуализации планового объема для каждого потребителя по всем местам потребления в совокупности. Какого рода визуализация тут подразумевается (просто цифры, графики, диаграммы, что-то иное)?

Răspuns (26 sept 2024, 14:50):

Визуализация плановых объемов должна осуществляться в табличной форме, структурированной по периодам и давлениям.

Data:

26 sept 2024, 08:43

Subiectul întrebării:

Биллинг

Întrebare:

• Цитата из ТЗ: “В ИС должен быть предусмотрен функционал настройки правил и параметров синхронизации данных с поставщиками природного газа для приема показаний, указанных в квитанциях. Система должна предусмотреть различные настройки приема данных от каждого поставщика по определенным циклам расчета, согласно бизнес-правилам.” Не могли бы вы описать какие правила и параметры должны быть использованы для настройки синхронизации? • В ТЗ упоминается интеграция с CRM для автоматического обновления статуса отправки и получения писем в системе управления взаимоотношениями с клиентами. Под этим требованием подразумевается CRM система контакт-центра? • Согласно ТЗ, функционал Data Warehouse должен поддерживать аналитические инструменты для глубокого анализа данных, позволяющие формировать отчеты и прогнозы. Не могли бы вы пояснить какие именно аналитические инструменты вам необходимы для этого?

Răspuns (26 sept 2024, 14:53):

Цитата из ТЗ: “ 3.1.1. Прием показаний и объемов от Распределительных предприятий Цитата из ТЗ: “В ИС должен быть предусмотрен функционал настройки правил и параметров синхронизации данных с распределительными предприятиями для приема данных по рассчитанному объему. Система должна предусмотреть различные настройки приема данных от каждого распределительного предприятия по определенным циклам расчета, согласно бизнес-правилам. Функционал для импорта/приема объемов по распределительным предприятиям должен унаследовать бизнес-правила описанные в блоке синхронизации (пункт 3.2.7).” Касательно синхронизации посмотреть Приложение 1,3 и 4 из ТЗ. Цитата из ТЗ: “ 3.1.2. Data Warehouse Data Warehouse - это единое хранилище архивных данных, предназначенных для выполнения запросов об исторических данных, необходимых для выполнения производственных задач, таких как: • Предоставление информации и финансовых документов по запросам клиентов через личный кабинет. • Выдача дубликатов финансовых документов по запросам потребителя или внутренним запросам. • Сохранение корреспонденции, исходящей в адрес потребителя в процессе работы с дебиторской задолженностью. Данный функционал унаследует общие функциональные требования к системе.”

Data:

26 sept 2024, 08:44

Subiectul întrebării:

Требования к взаимодействию с внешними информационными системами

Întrebare:

• Касательно интеграций с Агентствами государственных услуг, Системой моментальных платежей «MIA», Информационных систем поставщиков природного газа, находится ли API документация указанных сервисов в открытом доступе? Нам хотелось бы заранее изучить эту документацию и убедиться в том, что на этапе разработки и интеграции ПО не возникнет проблем

Răspuns (26 sept 2024, 13:16):

Касательно интеграций с Агентствами государственных услуг, Системой моментальных платежей «MIA» Данная документация не находится в отрытом доступе, и Заказчик не владеет ею, поэтому и было поставлено требования о наличие опыта работы с системами публичных структур Республики Молдова. Касательно “Информационных систем поставщиков природного газа”, интеграция и протокол взаимодействия должен разрабатываться на этапе внедрения, поскольку данные системы будут разработаны параллельно.

Sistem informațional pentru activitatea de furnizare a gazelor naturale

Data:

26 sept 2024, 13:01

Subiectul întrebării:

Furnizare cod-sursa

Întrebare:

Cerințele privind furnizarea codului sursă sunt neclare. Pe de o parte, nu se limitează participarea ofertanților care propun soluții comerciale, însă, pe de altă parte, se solicită prezentarea codului sursă pentru toate componentele. Vă informăm că, în mod obișnuit, soluțiile comerciale nu pot fi livrate împreună cu tot codul sursă. În plus, sistemele de operare (de ex. Windows) sau bazele de date (de ex. MS SQL, Oracle) nu vor furniza niciodată codul sursă. Vă rugăm să clarificați acest aspect.

Răspuns (26 sept 2024, 14:09):

Această cerință se aplică în mod specific componentelor care răspund de logica de business a sistemului (spre exemplu logica relalizată pe back-end sau front-end, ect). Scopul este de a asigura că beneficiarul poate dezvolta sistemul în continuare, fără a depinde de producătorul sau implementatorul soluției livrate. Evident, nu ne asteptam să fie furnizat codul sursă pentru componente precum sisteme de operare, baze de date, soluții de containere, virtualizare, etc. În cazul utilizării unor componente comerciale, care presupun costuri de licențiere, vor fi evaluate conform prevederilor Clauzei pct. 4.13.12 din Caietul de Sarcini.

Data:

27 sept 2024, 09:36

Subiectul întrebării:

Уточнения по процессу delivery

Întrebare:

Есть ли временнЫе ограничения? Есть ли необходимость в работах onsite? Каких именно?

Răspuns (27 sept 2024, 15:20):

Согласно пкт. 2.1.5. ТЗ, Точные детали будут указаны после установления протокола сотрудничества.

Data:

27 sept 2024, 09:38

Subiectul întrebării:

Технические уточнения:

Întrebare:

• Авторизация и аутентификация пользователей WEB интерфейса типографии (AD DS?) • Какой протокол должен поддерживать API ИС (REST, GraphQL...) • Предполагается ли интеграция с каким-либо спец оборудование от АО «Молдовагаз»? Если да, то каким? • Сформированы ли уже какие-либо требования к производительности системы (например, количество пользователей, запросов, транзакций в секунду, задержки, скорость интернет-соединения, обрывы связи и т.д.).

Răspuns (27 sept 2024, 15:24):

Подробное описание не может быть предоставлено в рамках процедуры закупки. Это является одним из результатов проекта. Реинжиниринг текущих процессов, включая бизнес-анализ процессов AS IS и разработку процессов TO BE, будет осуществляться в рамках проекта. Для получения более подробной информации ознакомьтесь с документацией процедуры закупки. Процессы, связанные с анализом и обработкой данных, будут проанализированы в рамках проекта. Также в рамках проекта будут определены наиболее подходящие инструменты для цифровизации этих процессов. Участник, в рамках настоящей процедуры закупки, может предложить любой инструмент. Условие заключается в том, чтобы он соответствовал требованиям технического задания, включая требования по лицензированию (пкт. 4.13.12. из ТЗ). Для информации: Функциональные требования не представляют собой исчерпывающий список желаемых функциональностей, они представляют собой часть текущих функциональностей существующей информационной системы. Окончательные функциональные требования будут определены в рамках проекта с использованием итеративной методологии внедрения. Очень важно, чтобы оценка необходимого усилия для реализации проекта проводилась не на основе функциональных требований, а на основе требований к разработке предложения (см. Объявление о участии, Требование - Оферта). Дополнительно рекомендуем ознакомиться с Частями 4 и 5 технического задания, где вы найдете ответы на часть возникших вопросов.

Data:

2 oct 2024, 16:19

Subiectul întrebării:

Integrarea cu sistemele informatice interne, cum ar fi Sistemul de Automatizare Contabilă (1C), Sistemul Contact Center, VOIP Gateway

Întrebare:

Va rugam sa ne comunicati ca aceste sisteme dispun de API (sau alt mecanism de transfer de date) si acesta este corespunzator documentat. In caz contrar, de confirmat de catre Achizitor ca este in responsabilitatea lui sa obtina aceste API-uri si documentatia aferenta.

Răspuns (3 oct 2024, 10:43):

Rugăm sa consultați adițional p. 4.3.7. și 4.3.8 din sarcina tehnică (Caiet de sarcini). Pentru sistemele declarate că vor fi integrate prin API, Beneficiarul are obligațiunea de a organiza accesurile și documentația necesară pentru integrare, pentru celelalte sisteme metodologia de integrare trebuie să fie definită, propusă și împreună în procesul de dezvoltare de comun acord cu beneficiarul să fie implementată.

Data:

2 oct 2024, 16:20

Subiectul întrebării:

Integrarea cu sisteme informatice externe, cum ar fi Agenția Servicii Publice (ASP) IS, Payment Gateway, Distribution Company Information System (OSD), Cabinet Personal, SMS Gateway

Întrebare:

Va rugam sa ne comunicati ca este in responsabilitatea Achizitorului sa obtina acces la aceste servicii, avand in vedere ca el este Beneficiarul si doar el isi poate face cont si obtine acces.

Răspuns (3 oct 2024, 10:44):

Data:

2 oct 2024, 16:20

Subiectul întrebării:

Organizează posibilitatea ca Tipografia să primească fișiere pentru imprimare folosind o interfață web specială.

Întrebare:

Va rugam sa specificati ce tip/format de fisiere poate utiliza Tipografia

Răspuns (3 oct 2024, 10:45):

La moment se utilizează PDF și CSV. În sistemul nou urmează să definim împreună în procesul de dezvoltare de comun acord.

Data:

2 oct 2024, 16:25

Subiectul întrebării:

Oracle DBMS este utilizat ca bază de date principală (clientul are licențe pentru a utiliza acest DBMS).

Întrebare:

Va rugam sa ne comunicati daca se accepta si SQL Server, caz in care va rugam sa confirmeati daca oferta trebuei sa prezinte si licente de SQL Server sau le va achizitiona Achizitorul separat.

Răspuns (3 oct 2024, 10:46):

Se acceptă orice SGBD care va corespunde cerințelor de productivitate. În caz că sunt produse comerciale, rugăm să consultați p. 5.2.1 (Caiet de sarcini).

Data:

2 oct 2024, 16:25

Subiectul întrebării:

Toate jurnalele cu jurnale IS trebuie stocate într-un DBMS separat (jurnal DB din diagramă)

Întrebare:

Va rugam sa ne comunicati care este perioada necesara de pastrate a jurnalelor.

Răspuns (3 oct 2024, 10:46):

Min 24 luni, cu posibilitate de a programa ștergerea la discreția beneficiarului.

Data:

2 oct 2024, 16:26

Subiectul întrebării:

Integrarea cu gateway-ul de telefonie IP (VOIP Gateway în diagramă) este necesară pentru a efectua apelarea automată și manuală a consumatorilor.

Întrebare:

Va rugam sa ne confirmati ca este in responsabilitatea achizitorului sa obtina acces pentru integrarea tehnica cu acest sistem, acesta fiind in proprietatea acestuia si avend relatii contractuale directe cu furnizorul acestei solutii.

Răspuns (3 oct 2024, 10:47):

Se utilizează Asterisk, care posedă documentație deschisă.

Data:

2 oct 2024, 16:27

Subiectul întrebării:

PI ar trebui să fie integrat cu API-urile băncilor comerciale și ale sistemelor de plată, inclusiv cu sistemul de plăți instantanee MIA (gateway de plată în sistem), pentru a face schimb rapid de informații privind tranzacțiile financiare.

Întrebare:

Va rugam sa ne confirmati ca veti intermedia relatia cu tertele parti implicate pentru obtinerea accesului la API-urile sistemelor respective, precum si documentatiile actualizate ale acestora.

Răspuns (3 oct 2024, 10:48):

Beneficiarul are obligațiunea de a organiza accesurile și documentația necesară pentru integrare, totodată executorul va avea obligațiunea de purta discuții pe marginea subiectelor tehnice vizavi de integrate direct cu prestatorul de servicii.

Data:

2 oct 2024, 16:28

Subiectul întrebării:

SI ar trebui să fie integrat cu API-ul sistemelor informatice ale întreprinderilor de distribuție (OSD în diagramă) pentru a face schimb de informații despre consumatori, locuri de consum, volume de gaze naturale consumate etc.

Întrebare:

Va rugam sa ne confirmati ca este in responsabilitatea achizitorului sa obtina acces pentru integrarea tehnica cu acest sistem, acesta avand relatii contractuale directe cu furnizorul acestei solutii.

Răspuns (3 oct 2024, 10:49):

Sistemul informațional pentru activitatea de furnizare și distribuție (OSD) vor fi elaborate concomitent, respectiv tot la acel moment se va dezvolta și protocolul API pentru integrarea între ele. Vezi detalii în p.4.4. din Caietului de Sarcini.

Data:

2 oct 2024, 16:29

Subiectul întrebării:

Contul personal al consumatorului (în diagramă - Cont personal).

Întrebare:

Va rugam sa ne confirmati daca exista deja si daca ne-ati putea indica cate informatii de concretizare.

Răspuns (3 oct 2024, 10:50):

Da, există.

Data:

2 oct 2024, 16:30

Subiectul întrebării:

„Contractantul se poate oferi să dezvolte un sistem informațional de la zero sau să ofere servicii de personalizare a platformelor tehnologice existente, a cadrelor și/sau a altor module sau instrumente personalizabile.

Întrebare:

Pentru acest scenariu, cum se calculeaza punctajul, avand in vedere ca pentru personalizare volumul de ManDay nu o sa mai fie >10 000, iar componenta de cost se va duce catre licente si nu catre dezvoltare?

Răspuns (3 oct 2024, 10:50):

In ofertă se va include costul efortului pentru fiecare specialist în parte și adițional celelalte costuri ce țin de licențe, configurare, ajustare și implementare. Consultați Anunțul de participare, vezi Anexa nr. 2 și Anexa nr. 2a.

Data:

2 oct 2024, 16:30

Subiectul întrebării:

„Indiferent de scenariul ales, trebuie îndeplinită următoarea cerință: toate componentele soluțiilor furnizate trebuie să fie însoțite de un cod sursă necompilat acoperit de o licență de utilizare nelimitată pentru SI Managementul Aprovizionării cu Gaze Naturale.

Întrebare:

Avand in vedere ca 2.1.2 mai sus permite utilizarea de platforme tehnologice existente, pentru acestea nu se poate pune la dispozitie codul sursa. Va rugam sa ne confirmati sau sa aduceti concretizari.

Răspuns (3 oct 2024, 10:51):

Lipsa codului sursă nu se acceptă.

Data:

2 oct 2024, 16:31

Subiectul întrebării:

Numărul cadastral al locului de consum/alt document de proprietate.

Întrebare:

Va rugam sa ne comunicati care care dintre campuri (in general) sunt obligatorii si care sunt optionale.

Răspuns (3 oct 2024, 10:52):

O descriere detaliată nu poate fi furnizată în cadrul procedurii de achiziție. Aceasta reprezintă unul dintre livrabilele proiectului. Reingineria proceselor actuale, inclusiv analiza business a proceselor AS IS și elaborarea proceselor TO BE vor fi efectuate în cadrul proiectului. Pentru mai multe detalii, consultați documentația procedurii de achiziție. Procesele ce țin de analiza și procesarea datelor vor fi analizate în cadrul proiectului. Tot în cadrul proiectului, vor fi identificate instrumentele cele mai potrivite pentru digitalizarea acestor procese. Ofertantul, în cadrul prezentei proceduri de achiziție, poate propune orice instrument. Condiția este să corespundă cerințelor caietului de sarcini, inclusiv cerințelor de licențiere (pct.4.13.12. din Caietul de Sarcini). Pentru informare: Cerințele funcționale nu reprezintă lista exhaustivă a funcționalităților dorite. Ele reprezintă o parte din funcționalitățile curente ale sistemului informațional existent. Cerințele funcționale finale vor fi identificate în cadrul proiectului, prin utilizarea unei metodologii iterative de implementare. Este foarte important ca estimarea efortului necesar pentru realizarea proiectului să se efectueze nu în baza cerințelor funcționale, ci în baza cerințelor privind elaborarea ofertei (a se vedea Anunțul de participare, Cerința - Oferta).

Data:

2 oct 2024, 16:31

Subiectul întrebării:

Funcționalitate care permite schimbul bidirecțional de date în timp real între furnizor și companiile de distribuție incluse în sistemul JSC

Întrebare:

Va rugam sa ne spuneti daca sistemul JSC are APPI si de catre cine este gestionat.

Răspuns (3 oct 2024, 10:53):

Sistemul informaționale pentru activitatea de furnizare și distribuție (OSD) vor fi elaborate concomitent, respect tot la acel moment se va dezvolta și protocolul API pentru integrarea între ele. Vezi detalii în p.4.4. din Caietul de Sarcini.

Data:

2 oct 2024, 16:43

Subiectul întrebării:

Reputația consumatorului este valoarea caracteristicilor statutului consumatorului, a acțiunilor efectuate asupra consumatorului (deconectat, conectat, cerere, proces în instanță, hotărâre judecătorească, titlu executoriu, proces de insolvență etc.).

Întrebare:

Va rugam sa ne comunicati daca pentru stabilirea retutatiei consumatorilor se foloseste o procedura standard, acceptata/stabilita la nivel national sau o procedura interna.

Răspuns (3 oct 2024, 10:53):

Data:

2 oct 2024, 16:43

Subiectul întrebării:

Istoricul schimbărilor de reputație.

Întrebare:

Va rugam sa ne comunicati de unde este preluat acest istoric, din SI sau dintr-un sistem/registru national, eventua prin ingerare?

Răspuns (3 oct 2024, 10:54):

Data:

2 oct 2024, 16:44

Subiectul întrebării:

1C si Sistemul CRM al centrului de contact

Întrebare:

Confirmati va rog daca asigurati accesul la aceste API-uri, prin prisma relatiei contractuale cu vendorul acestor solutii.

Răspuns (3 oct 2024, 10:55):

Rog sa consultați adițional p. 4.3.7. și 4.3.8 din sarcina tehnică (Caietul de Sarcini). Pentru sistemele declarate că vor fi integrate prin API, Beneficiarul are obligațiunea de a organiza accesurile și documentația necesară pentru integrare, pentru celelalte sisteme metodologia de integrare trebuie să fie definită, propusă și împreună în procesul de dezvoltare de comun acord cu beneficiarul să fie implementată.

Data:

2 oct 2024, 16:44

Subiectul întrebării:

API al Agenției Servicii Publice; ● API-urile băncilor comerciale și ale sistemelor de plată, inclusiv sistemul de plăți instant MIA; ● API-ul sistemelor informatice ale întreprinderilor de distribuție;

Întrebare:

Va rugam sa ne confirmati daca asigurati accesul la aceste API-uri, prin prisma relatiei contractuale cu vendorul acestor solutii.

Răspuns (3 oct 2024, 10:56):

Data:

2 oct 2024, 16:46

Subiectul întrebării:

API-ul contului personal al consumatorului

Întrebare:

Mentionam ca in CS nu se specifica daca trebuie sa facem si acest portal sau exista deja. Va rugam sa clarificati

Răspuns (3 oct 2024, 10:57):

Nu necesită elaborat, există deja.

Data:

2 oct 2024, 16:48

Subiectul întrebării:

IS ar trebui să permită personalizarea interfeței cu utilizatorul, inclusiv a formularelor. SI ar trebui să permită crearea de noi formulare de utilizator pentru a accesa logica de afaceri a sistemului informatic.

Întrebare:

Vă rugăm să detaliați la ce vă referiți exact în privința posibilității de creare a formularelor. Este vorba despre crearea acestora de către utilizator sau de către Provider? De asemenea, vă rugăm să clarificați dacă aceste specificații pot varia (și să fie superioare) față de cele menționate anterior în caietul de sarcini.

Răspuns (3 oct 2024, 10:58):

O descriere detaliată nu poate fi furnizată în cadrul procedurii de achiziție. Aceasta reprezintă unul dintre livrabilele proiectului. Reingineria proceselor actuale, inclusiv analiza business a proceselor AS IS și elaborarea proceselor TO BE vor fi efectuate în cadrul proiectului. Pentru mai multe detalii, consultați documentația procedurii de achiziție. Procesele ce țin de analiza și procesarea datelor vor fi analizate în cadrul proiectului. Tot în cadrul proiectului, vor fi identificate instrumentele cele mai potrivite pentru digitalizarea acestor procese. Ofertantul, în cadrul prezentei proceduri de achiziție, poate propune orice instrument. Condiția este să corespundă cerințelor caietului de sarcini, inclusiv cerințelor de licențiere (pct. 4.13.12. din Caietul de Sarcini). Pentru informare: Cerințele funcționale nu reprezintă lista exhaustivă a funcționalităților dorite. Ele reprezintă o parte din funcționalitățile curente ale sistemului informațional existent. Cerințele funcționale finale vor fi identificate în cadrul proiectului, prin utilizarea unei metodologii iterative de implementare. Este foarte important ca estimarea efortului necesar pentru realizarea proiectului să se efectueze nu în baza cerințelor funcționale, ci în baza cerințelor privind elaborarea ofertei (a se vedea Anunțul de participare, Cerința - Oferta).

Data:

2 oct 2024, 16:49

Subiectul întrebării:

PI ar trebui să fie dezvoltat și operat pe baza tehnologiilor cunoscute și implementate pe scară largă în Republica Moldova. Cel puțin alți trei contractanți de pe piața locală sunt obligați să furnizeze servicii de întreținere și dezvoltare pe platformele relevante.

Întrebare:

Cum considerați cerința de predare a codului sursă în cazul utilizării platformelor comerciale off the shelf (COTS), având în vedere că aceste soluții nu necesită predarea codului sursă? De asemenea, cum se va ajusta punctajul, dat fiind că implementarea cu o soluție COTS ar putea reduce semnificativ numărul de ore necesare, posibil sub 10.000?

Răspuns (3 oct 2024, 10:59):

Dacă oferta nu presupune predarea codului sursă, ea nu va întruni cerințele. Dacă soluția comercială presupune ore sub 10 000, atunci impune adăugarea la ofertă costul tuturor componentelor ale sistemului care vor necesita achiziție (vezi Anexa nr. 2 si nr. 2a din Anunțului de participare).

Data:

2 oct 2024, 16:49

Subiectul întrebării:

Implementarea SI va necesita transformarea și migrarea datelor istorice. Clientul va pregăti și furniza seturile de date necesare pentru transformarea și finalizarea bazei de date IS. Formatul datelor va fi convenit de comun acord între Contractor și Client.

Întrebare:

Ne puteți clarifica pentru ce perioadă istorică se intenționează migrarea datelor?

Răspuns (3 oct 2024, 10:59):

Toate datele istorice din anul 2017.

Data:

2 oct 2024, 16:49

Subiectul întrebării:

Toate rapoartele existente în software-ul actual trebuie implementate în IS

Întrebare:

Ar fi posibil să furnizați o listă a rapoartelor, împreună cu o scurtă descriere a scopului fiecăruia și, eventual, departamentul sau zona de business care le utilizează?

Răspuns (3 oct 2024, 11:00):

Vezi p. 4.6.11., Anexa nr.5 din Caietul de Sarcini.

Doar utilizatorii autorizați ai platformei pot să adreseze întrebări în perioada de clarificări.