Sistem informațional pentru activitatea de furnizare a gazelor naturale

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.

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

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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.

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.

Da, există.

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.

Lipsa codului sursă nu se acceptă.

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

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.

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

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

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

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

Nu necesită elaborat, există deja.

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

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

Toate datele istorice din anul 2017.

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