Sistem informațional pentru activitatea de furnizare a gazelor naturale
suma planificată 52,600,000.00 MDL
Valoare | CPV | Titlu achiziției | Cantitate | Livrare |
---|---|---|---|---|
52,600,000.00 MDL | 48445000-9 | Sistem informațional pentru activitatea de furnizare a gazelor naturale | 1 Unitate |
01.11.2024 - 30.12.2027 Alexandr Puskin nr.64 |
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)?
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.
Î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.
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.
• Не могли бы Вы пояснить что Вы подразумеваете функциональной возможностью копирования данных для дальнейшего использования?
• Вы указываете о возможности настройка уведомлений или оповещений при изменении важных данных. Правильно ли мы понимаем, что тут подразумеваются не только уведомления, которые строго привязаны к каким-либо событиям в ИС, но и возможность отправлять дополнительные уведомления пользователям, например, Администратором Системы при необходимости?
В основном это сообщения потребителям, но есть и процессы, по которым нужно оповестить и внутренних пользователей.
• Вы упоминаете, что справочники должны обновлять данные на основе Государственного Регистра через web-сервис. Должна ли запускаться процесс синхронизации, как только данные на стороне Государственного Регистра были изменены/обновлены?
• В техническом задании указана необходимость наличия конструктора/редактора шаблонов документов, который использует справочник «Шаблоны документов». Подразумевается ли здесь полноценный конструктор шаблонов документов, как например Fast Reports (или что-то подобное с аналогичным функционалом)?
• Может ли пользователь создавать новые справочники, помимо тех, которые должны обязательно существовать в соответствии с техническим заданием?
• Если пользователю необходимо удалить какую-либо запись из выбранного справочника, при этом эта запись использована, например, в карточке потребителя, и является обязательным атрибутом, то как быть в такой ситуации? Запрещать удаление в принципе? Или реализовать логику, согласно которой можно назначить иную запись из справочника для всех потребителей, который попадают под эффект удаления записи?
Вы упоминаете, что справочники должны обновлять данные на основе Государственного Регистра через web-сервис. Должна ли запускаться процесс синхронизации, как только данные на стороне Государственного Регистра были изменены/обновлены? Нет, данные должны обновляется по запросу со стороны Заказчика (планировщик и/или ручной режим) В техническом задании указана необходимость наличия конструктора/редактора шаблонов документов, который использует справочник «Шаблоны документов». Подразумевается ли здесь полноценный конструктор шаблонов документов, как например Fast Reports (или что-то подобное с аналогичным функционалом)? Наличие конструктора/редактора шаблонов документов обязательно, а реализация может быть в как Fast Report и даже использовать MS Word как редактор шаблонов. Детализация будет на этапе внедрения. • Может ли пользователь создавать новые справочники, помимо тех, которые должны обязательно существовать в соответствии с техническим заданием? Да • Если пользователю необходимо удалить какую-либо запись из выбранного справочника, при этом эта запись использована, например, в карточке потребителя, и является обязательным атрибутом, то как быть в такой ситуации? Запрещать удаление в принципе? Или реализовать логику, согласно которой можно назначить иную запись из справочника для всех потребителей, который попадают под эффект удаления записи? Данные из справочников будут служить для заполнения карточек объектов, а после сохранения объекта связь теряется. Тем не менее случаи будут разные и для каждого будут свои правила, которые обседаться на этапе разработки.
• В техническом задании указана возможность интеграции с внешними источниками для автоматического обновления данных потребителей. Здесь подразумевается Государственный Регистр или иная внешняя ИС?
• Согласно техническому заданию, карточка потребителя должна содержать данные о репутации потребителя, и обновление репутации происходит в соответствии с бизнес-правилами. Это требование имеет ссылку на отсутствующий раздел в ТЗ. Не могли бы предоставить немного деталей о механизмах расчета репутации потребителей?
В зависимости что конкретно вы подразумеваете под данным вопросом, у нас предусмотрено и то, и то.
Î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.
Vă rugăm să vizualitați răspunsul de mai sus.
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.
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.
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ă?
Да, допускается возможность назначать более чем одну группу прав доступа для пользователя.
• Вы указываете о необходимости наличия визуализации планового объема для каждого потребителя по всем местам потребления в совокупности. Какого рода визуализация тут подразумевается (просто цифры, графики, диаграммы, что-то иное)?
Визуализация плановых объемов должна осуществляться в табличной форме, структурированной по периодам и давлениям.
• Цитата из ТЗ: “В ИС должен быть предусмотрен функционал настройки правил и параметров синхронизации данных с поставщиками природного газа для приема показаний, указанных в квитанциях. Система должна предусмотреть различные настройки приема данных от каждого поставщика по определенным циклам расчета, согласно бизнес-правилам.” Не могли бы вы описать какие правила и параметры должны быть использованы для настройки синхронизации?
• В ТЗ упоминается интеграция с CRM для автоматического обновления статуса отправки и получения писем в системе управления взаимоотношениями с клиентами. Под этим требованием подразумевается CRM система контакт-центра?
• Согласно ТЗ, функционал Data Warehouse должен поддерживать аналитические инструменты для глубокого анализа данных, позволяющие формировать отчеты и прогнозы. Не могли бы вы пояснить какие именно аналитические инструменты вам необходимы для этого?
Цитата из ТЗ: “ 3.1.1. Прием показаний и объемов от Распределительных предприятий Цитата из ТЗ: “В ИС должен быть предусмотрен функционал настройки правил и параметров синхронизации данных с распределительными предприятиями для приема данных по рассчитанному объему. Система должна предусмотреть различные настройки приема данных от каждого распределительного предприятия по определенным циклам расчета, согласно бизнес-правилам. Функционал для импорта/приема объемов по распределительным предприятиям должен унаследовать бизнес-правила описанные в блоке синхронизации (пункт 3.2.7).” Касательно синхронизации посмотреть Приложение 1,3 и 4 из ТЗ. Цитата из ТЗ: “ 3.1.2. Data Warehouse Data Warehouse - это единое хранилище архивных данных, предназначенных для выполнения запросов об исторических данных, необходимых для выполнения производственных задач, таких как: • Предоставление информации и финансовых документов по запросам клиентов через личный кабинет. • Выдача дубликатов финансовых документов по запросам потребителя или внутренним запросам. • Сохранение корреспонденции, исходящей в адрес потребителя в процессе работы с дебиторской задолженностью. Данный функционал унаследует общие функциональные требования к системе.”
• Касательно интеграций с Агентствами государственных услуг, Системой моментальных платежей «MIA», Информационных систем поставщиков природного газа, находится ли API документация указанных сервисов в открытом доступе? Нам хотелось бы заранее изучить эту документацию и убедиться в том, что на этапе разработки и интеграции ПО не возникнет проблем
Касательно интеграций с Агентствами государственных услуг, Системой моментальных платежей «MIA» Данная документация не находится в отрытом доступе, и Заказчик не владеет ею, поэтому и было поставлено требования о наличие опыта работы с системами публичных структур Республики Молдова. Касательно “Информационных систем поставщиков природного газа”, интеграция и протокол взаимодействия должен разрабатываться на этапе внедрения, поскольку данные системы будут разработаны параллельно.
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.
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.
Есть ли временнЫе ограничения?
Есть ли необходимость в работах onsite? Каких именно?
Согласно пкт. 2.1.5. ТЗ, Точные детали будут указаны после установления протокола сотрудничества.
• Авторизация и аутентификация пользователей WEB интерфейса типографии (AD DS?)
• Какой протокол должен поддерживать API ИС (REST, GraphQL...)
• Предполагается ли интеграция с каким-либо спец оборудование от АО «Молдовагаз»? Если да, то каким?
• Сформированы ли уже какие-либо требования к производительности системы (например, количество пользователей, запросов, транзакций в секунду, задержки, скорость интернет-соединения, обрывы связи и т.д.).
Подробное описание не может быть предоставлено в рамках процедуры закупки. Это является одним из результатов проекта. Реинжиниринг текущих процессов, включая бизнес-анализ процессов AS IS и разработку процессов TO BE, будет осуществляться в рамках проекта. Для получения более подробной информации ознакомьтесь с документацией процедуры закупки. Процессы, связанные с анализом и обработкой данных, будут проанализированы в рамках проекта. Также в рамках проекта будут определены наиболее подходящие инструменты для цифровизации этих процессов. Участник, в рамках настоящей процедуры закупки, может предложить любой инструмент. Условие заключается в том, чтобы он соответствовал требованиям технического задания, включая требования по лицензированию (пкт. 4.13.12. из ТЗ). Для информации: Функциональные требования не представляют собой исчерпывающий список желаемых функциональностей, они представляют собой часть текущих функциональностей существующей информационной системы. Окончательные функциональные требования будут определены в рамках проекта с использованием итеративной методологии внедрения. Очень важно, чтобы оценка необходимого усилия для реализации проекта проводилась не на основе функциональных требований, а на основе требований к разработке предложения (см. Объявление о участии, Требование - Оферта). Дополнительно рекомендуем ознакомиться с Частями 4 и 5 технического задания, где вы найдете ответы на часть возникших вопросов.
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.
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).
Va rugam sa ne comunicati daca pentru stabilirea retutatiei consumatorilor se foloseste o procedura standard, acceptata/stabilita la nivel national sau o procedura interna.
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).
Va rugam sa ne comunicati de unde este preluat acest istoric, din SI sau dintr-un sistem/registru national, eventua prin ingerare?
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).
Confirmati va rog daca asigurati accesul la aceste API-uri, prin prisma relatiei contractuale cu vendorul acestor solutii.
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ă.
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?
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.
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.
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ă.