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

Дата:

19 сен 2024, 10:08

Название вопроса:

Dublare de anunt

Вопрос:

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?

Ответ (20 сен 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.

Дата:

26 сен 2024, 08:48

Название вопроса:

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

Вопрос:

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

Ответ (27 сен 2024, 15:35):

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

Дата:

26 сен 2024, 08:48

Название вопроса:

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

Вопрос:

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

Ответ (27 сен 2024, 15:36):

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

Дата:

26 сен 2024, 08:49

Название вопроса:

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

Вопрос:

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

Ответ (27 сен 2024, 15:36):

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

Дата:

26 сен 2024, 08:49

Название вопроса:

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

Вопрос:

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

Ответ (27 сен 2024, 15:37):

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

Дата:

26 сен 2024, 08:49

Название вопроса:

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

Вопрос:

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

Ответ (27 сен 2024, 15:39):

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

Дата:

26 сен 2024, 08:49

Название вопроса:

Биллинг

Вопрос:

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

Ответ (27 сен 2024, 15:38):

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

Дата:

26 сен 2024, 08:50

Название вопроса:

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

Вопрос:

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

Ответ (27 сен 2024, 15:38):

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

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

Дата:

26 сен 2024, 13:03

Название вопроса:

Furnizare cod-sursa

Вопрос:

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.

Ответ (27 сен 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.