Achiziționarea sistemei informaționale pentru activitatea de distribuție a gazelor naturale

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 Moldova Gaz. https://achizitii.md/en/public/tender/21278443/ Este o eroare, sau cum se explica aceasta?

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

Nu este dublare de anunț, sunt două achiziții diferite. SRL ,,Chișinău-gaz” va achiziționa Sistemul informațional pentru activitatea de distribuție a gazelor naturale, iar SA ,,Moldovagaz” va achiziționa Sistemul informațional pentru activitatea de furnizare a gazelor naturale. Dat fiind faptul că sunt 2 proceduri diferite, respectiv sunt și 2 Caiete de sarcini diferite specific activității.

Data:

26 sept 2024, 08:48

Subiectul întrebării:

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

Întrebare:

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

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

- Да, допускается возможность назначать более чем одну группу прав доступа для пользователя; - Да, Администратор будет выполнять мониторинг выполнения запросов к базе данных и не только, также он должен мониторить всю систему в целом как: ресурсы операционной системы, базы денных, коммуникация системы, аудиты на всех уровнях и т.д. - Он должен организовать по предварительно созданному шаблону соединение для взаимодействия через API со сторонними системами (например, для обмена данными с оператором распределительной сети)

Data:

26 sept 2024, 08:48

Subiectul întrebării:

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

Întrebare:

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

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

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

Data:

26 sept 2024, 08:49

Subiectul întrebării:

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

Întrebare:

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

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

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

Data:

26 sept 2024, 08:49

Subiectul întrebării:

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

Întrebare:

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

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

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

Data:

26 sept 2024, 08:49

Subiectul întrebării:

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

Întrebare:

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

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

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

Data:

26 sept 2024, 08:49

Subiectul întrebării:

Биллинг

Întrebare:

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

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

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

Data:

26 sept 2024, 08:50

Subiectul întrebării:

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

Întrebare:

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

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

- К сожалению, документация по подключению через API не находится в открытом доступе, но документация будет предоставляться По мере разработки ИС

Achiziționarea sistemei informaționale pentru activitatea de distribuție a gazelor naturale

Data:

26 sept 2024, 13:03

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 (27 sept 2024, 15:38):

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 4.13.12.