Поставка и внедрение инструмента по контролю качества данных

Добрый день! Укажите, пожалуйста, конкретные пункты ТЗ, по вашим вопросам. Спасибо.

На данный момент, шаблон договора в документации, для ознакомления. Поля, которые залиты серым цветом будут корректироваться. Финальный проект договора будет приложен непосредственно к процедуре закупки.

Добрый день! 1. Срок подачи заявок продлен до 17:00, 03.04.2026. 2. На данный момент мы исследуем рынок и ожидаем 10 проектов с разными компаниями. Предоставьте информацию, сколько сможете подтвердить? 3. Количество проверок небольшое. 4. Есть, сначала будут мигрированы проверки, которые влияют на ключевые процессы компании.

Добрый день! 1. Срок подачи заявок продлен до 17:00, 03.04.2026. 2. На данный момент мы исследуем рынок и ожидаем 10 проектов с разными компаниями. Предоставьте информацию, сколько сможете подтвердить 3. Количество проверок небольшое. 4. Есть, сначала будут мигрированы проверки, которые влияют на ключевые процессы компании.

Добрый день! - Является ли разрабатываемая Система ИСПДн? Из ТЗ в явном виде не понятно. – Системы не является системой ИСПДн, но она использует критичные данные, в том числе ИСПДн, поэтому требования к ней предъявляются как к системе ИСПДн. - Проведение оценки Системы соответствию государственным нормативным требованиям по ИБ является обязательным (Пункт 7.3 Требования ИБ)? Система не является ГИС и требования по обязательной оценке или аттестации на нее не распространяются. Требования предъявляются не к поставщику, а к самой системе. Проверка соответствию требованиям обязательна. - Кто будет проводить оценку Системы соответствию государственным нормативным требованиям по ИБ (Заказчик или Исполнитель)? Сама процедура оценки по всем требованиям законодательства с предоставлением результатов во ФСТЭК довольно трудоемка, дорогостояща и может занять до года. Да оценка проводится будет. Оценка будет проводится на стороне Т2. - Пункт 7.3 содержит требование наличия лицензии ФСБ у Исполнителя, хотя никаких видов работ требующих данной лицензии в документации явно не указано. Можно ли исключить данное требование? – Не актуально. Просьба обратить внимание, в документации изменен файл "Приложение_1._Техническое_задание".

Добрый день! Ответы в приложенном файле. На текущий момент, готовы продлить процедуру до 17:00, 03.04.2026. Продление на более позднюю дату рассматривается.

Добрый день! Ответить необходимо только по видимым строкам. Спасибо.

Добрый день! 1) Проверки строятся на хранилищах. Основная часть проверок это Teradata, Oracle, postgres, Hadoop. Также есть проверки на SAP BW, ClickHouse. Планируются на Kafka. 2) Просьба уточнить, для чего эта информация? Мы не проверяем ВСЕ хранилище, только отдельные объекты. 3) Разный. От нескольких десятков строк до млн. строк. 4) Обращение к таблице с трафиком (одна из самых больших витрин) - 2 дня считалось 12 минут, потребило 1,13Т спула, обработало 46млн строк. 5) Сейчас проверок в режиме реального времени нет. Но нам требуется, чтобы система умела их делать, т.к. такие требования уже появляются. Пока близкие к реальному от раза в час, до раза в 15 минут. Но и объем данных здесь соответствующий, т.к. чем меньше интеграл, тем меньше обновлений нужно проверять. 6) Проверки должны быть гибки и подстраиваться под требования пользователей. Например, группировка в проверке может быть не только по дню, но и по отдельному признаку или группе признаков (как пример: регион, тип платежа, тип абонента и т.п.). Система DQ должна уметь сравнивать несколько систем между собой, должны учитывать календарные особенности в проверке (разделять выходные и будни, праздники и рабочие, начало и конец месяца и т.п.). Уметь использовать справочники, алиасы, группировки и т.п. Проверки должны уметь запускаться как по событию, как и по расписанию. Проверки можно остановить и запустить группами.

Добрый день! Да, допускается. Требования указаны в документе во вложении.

Добрый день! 1. Они там есть, но Teradata, Oracle, Hadoop, SapBW, Postrges, MSSQL , а так же система должна уметь ходить в 1С, S3, trino, rockDB. 2. Умение проверять что в этот транспорт попали данные. 3. Да 4. Коннекторы требуются как для чтения данных (да, используем данные из этих систем, делаем проверки), так и для передачи данных из системы DQ (например, для фактуры при заведении инцидента, чтобы описать о чем инцидент, где найдена ошибка, каким скриптом, примеры ошибок и т.п.). 5. Такой функционал нужен, чтобы бизнес пользователи сами могли заводить проверки качества данных на основании «конструктора». Или напрямую, зависит от функционала системы. Нужно, чтобы пользователь завел проверку, получил пример ошибок, убедился, что проверка удовлетворяет его желанию и дальше отправил запрос на постановку на расписание такой проверки. На стороне системы админ, провалидировав запрос (не создает нагрузку на БД и т.п.), одобрил или отклонил запрос с комментариями. 6. Перенос реализации и результатов проверок. 7. Не обязательно. BI отчеты возможны, то также могут быть письма на заранее определенные адреса (сотрудники, которые подписаны на отчет) с кастомным подходом. Это может быть полный файл со всеми ошибками и текстовом, описывающим ошибки. Либо просто аларм, о том, что ошибка обнаружена, за такой-то период в таком-то объеме. 8. Как правило да. 9. Да, процессы, которые сопровождают процесс управления данными, которые не включены в корневую систему. Например таким образом переносится информация из системы инцидент менеджмента в канал для бизнеса в труконф, такими же данными обновляются статусы DQ инцидентов и т.д. Также такие даги заводят инциденты и т.п. 10. С точки зрения пользователя (группы пользователя и доступ моет быть разным) он заходит в систему, видит список проверок (группы проверок), на проверки можно подписаться и видеть в отдельном окне только те проверки, на которые подписан. Видно историю выполнения проверок (факт), видно результат выполнения проверок по дням. И список ошибок, которые найдены. Так же есть разрезы по кол-ву проверок, систем, КХД и т.п. (разные разрезы), уровень качества данных в этих разрезах и в целом. Есть возможность подписаться на результаты как в интерфейсе, так и через почту по условиям пользователя (например, кол-во ошибок превышает 10). Это верхнеуровнево и только для пользователя, для разработчика конечно будет разница. 11. FineBI, SAPBO. По ИБ: 1. Да, с Пдн и чувствительными данными и с тайной связи.