Номер извещения: 0373100063326000040

Общая информация о закупке

Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Способ определения поставщика (подрядчика, исполнителя): Электронный аукцион

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: АО "РАД"

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: https://gz.lot-online.ru

Размещение осуществляет: Заказчик ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ КАЗЕННОЕ УЧРЕЖДЕНИЕ "ДИРЕКЦИЯ ПО СТРОИТЕЛЬСТВУ И ЭКСПЛУАТАЦИИ ОБЪЕКТОВ РОСГРАНИЦЫ"

Наименование объекта закупки: Оказание услуг по внедрению дополнительного модуля программно-аппаратного комплекса по обеспечению автоматизации системы управления работами и сопровождения для нужд ФГКУ Росгранстрой (в рамках ИКТ)

Этап закупки: Подача заявок

Сведения о связи с позицией плана-графика: 202603731000633001000155

Контактная информация

Размещение осуществляет: Заказчик

Организация, осуществляющая размещение: ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ КАЗЕННОЕ УЧРЕЖДЕНИЕ "ДИРЕКЦИЯ ПО СТРОИТЕЛЬСТВУ И ЭКСПЛУАТАЦИИ ОБЪЕКТОВ РОСГРАНИЦЫ"

Почтовый адрес: 107078, г. Москва, ул. Садовая-Спасская, д.18, стр.1.

Место нахождения: Российская Федерация, 107078, Москва, Садовая-Спасская ул, Д.18 СТР.1

Ответственное должностное лицо: Парамонова Д. Н.

Адрес электронной почты: info@rosgranstroy.ru

Номер контактного телефона: 7-495-7850334-0154

Дополнительная информация: Ответственное должностное лицо за описание объекта закупки: Бабушкин Роман Владимирович Контактный номер телефона: + 7 (495) 785-03-34 (доб. 0163)

Регион: Москва

Информация о процедуре закупки

Дата и время начала срока подачи заявок: 29.05.2026 12:47 (МСК)

Дата и время окончания срока подачи заявок: 08.06.2026 09:00 (МСК)

Дата проведения процедуры подачи предложений о цене контракта либо о сумме цен единиц товара, работы, услуги: 08.06.2026

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 10.06.2026

Начальная (максимальная) цена контракта

Начальная (максимальная) цена контракта: 97 000 000,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Размер аванса, %: 30,00

Идентификационный код закупки (ИКЗ): 261770982726677080100101020010000242

Информация о сроках исполнения контракта и источниках финансирования

Срок исполнения контракта (отдельных этапов исполнения контракта) включает в том числе приемку поставленного товара, выполненной работы, оказанной услуги, а также оплату заказчиком поставщику (подрядчику, исполнителю) поставленного товара, выполненной работы, оказанной услуги

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 28.12.2026 Сроки исполнения отдельных этапов исполнения контракта определяются на основании заявок заказчика в порядке, предусмотренном контрактом

Количество этапов: 13

Закупка за счет бюджетных средств: Да

Наименование бюджета: Федеральный бюджет

Вид бюджета: федеральный бюджет

Код территории муниципального образования: 00000001: Раздел 1. Муниципальные образования субъектов Российской Федерации / Федеральный бюджет

Информация об объекте закупки

Код позиции - Наименование товара, работы, услуги - Ед. измерения - Количество (объем работы, услуги) - Цена за ед., ? - Стоимость, ?

- 62.02.30.000 - Предоставление сертификата на оказание технической поддержки Цели предоставления сертификата технической поддержки Целью технической поддержки является обеспечение бесперебойной эксплуатации программного обеспечения «АСУР», минимизация рисков сбоев и нарушений в работе системы, своевременное устранение неисправностей и решение возникающих вопросов пользователей. Срок оказания технической поддержки с 01.07.2026 года по 01.07.2027 года включительно Режимы оказания технической поддержки Стандартный режим (рабочие дни): Время предоставления поддержки: с понедельника по пятницу с 09:00 до 18:00 по московскому времени; Срок реакции на обращение: не позднее 4 часов с момента получения заявки; Решение срочных вопросов: не более 24 часов. Экстренный режим (внеплановые инциденты): Круглосуточная доступность службы техподдержки в случае критического сбоя, влияющего на работу всей системы; Максимальное время реакции на экстренные обращения — 30 минут; Необходимость разрешения проблемы — в течение 12 часов. Методы взаимодействия с пользователями Телефонная связь: Для срочной связи предусмотрена горячая линия. Телефонные консультации проводятся в рабочее время стандартного режима. Телефон технической поддержки должен быть прописан и закреплен в сертификате технической поддержки. Электронная почта: Пользователи могут отправлять запросы на электронный адрес службы поддержки. Оперативность ответа на электронные письма — не более 4 часов. Электронная почта технической поддержки должна быть прописана и закреплена в сертификате технической поддержки. Требования к квалификации специалистов техподдержки Специалисты, предоставляющие техническую поддержку, должны обладать следующим набором компетенций: опыт работы с аналогичными программными комплексами; глубокие знания архитектуры и функционала программы «АСУР»; навыки диагностики и устранения ошибок в программном обеспечении; коммуникабельность и умение грамотно консультировать пользователей.» Состав предоставляемых услуг Техническая поддержка включает следующие виды услуг: Первичная диагностика проблем: анализ сообщений об ошибках, поступающих от пользователей; идентификация причины возникновения проблемы. Устранение неисправностей: исправление ошибок в коде программы; настройка конфигурации системы для восстановления её работоспособности. Консультативные услуги: ответы на запросы пользователей по вопросам использования программы; инструктаж по решению технических вопросов. Обновление ПО: выпуск обновлений программного обеспечения для исправления обнаруженных багов и добавления новых функций; установку обновлений на сервер заказчика в течении суток после выхода обновления. Мониторинг производительности: постоянный мониторинг работы сервера и базы данных; оптимизация производительности системы при необходимости. Документальная поддержка: обновление документации по использованию программы после выхода и установки обновлений ПО; разработка инструкций и рекомендаций для пользователей - Условная единица - 1,00 - 13 500 000,00 - 13 500 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Цели предоставления сертификата технической поддержки Целью технической поддержки является обеспечение бесперебойной эксплуатации программного обеспечения «АСУР», минимизация рисков сбоев и нарушений в работе системы, своевременное устранение неисправностей и решение возникающих вопросов пользователей. Срок оказания технической поддержки с 01.07.2026 года по 01.07.2027 года включительно Значение характеристики не может изменяться участником закупки Режимы оказания технической поддержки Стандартный режим (рабочие дни): Время предоставления поддержки: с понедельника по пятницу с 09:00 до 18:00 по московскому времени; Срок реакции на обращение: не позднее 4 часов с момента получения заявки; Решение срочных вопросов: не более 24 часов. Экстренный режим (внеплановые инциденты): Круглосуточная доступность службы техподдержки в случае критического сбоя, влияющего на работу всей системы; Максимальное время реакции на экстренные обращения — 30 минут; Необходимость разрешения проблемы — в течение 12 часов. Методы взаимодействия с пользователями Телефонная связь: Для срочной связи предусмотрена горячая линия. Телефонные консультации проводятся в рабочее время стандартного режима. Телефон технической поддержки должен быть прописан и закреплен в сертификате технической поддержки. Электронная почта: Пользователи могут отправлять запросы на электронный адрес службы поддержки. Оперативность ответа на электронные письма — не более 4 часов. Электронная почта технической поддержки должна быть прописана и закреплена в сертификате технической поддержки. Требования к квалификации специалистов техподдержки Специалисты, предоставляющие техническую поддержку, должны обладать следующим набором компетенций: опыт работы с аналогичными программными комплексами; глубокие знания архитектуры и функционала программы «АСУР»; навыки диагностики и устранения ошибок в программном обеспечении; коммуникабельность и умение грамотно консультировать пользователей.» Значение характеристики не может изменяться участником закупки Состав предоставляемых услуг Техническая поддержка включает следующие виды услуг: Первичная диагностика проблем: анализ сообщений об ошибках, поступающих от пользователей; идентификация причины возникновения проблемы. Устранение неисправностей: исправление ошибок в коде программы; настройка конфигурации системы для восстановления её работоспособности. Консультативные услуги: ответы на запросы пользователей по вопросам использования программы; инструктаж по решению технических вопросов. Обновление ПО: выпуск обновлений программного обеспечения для исправления обнаруженных багов и добавления новых функций; установку обновлений на сервер заказчика в течении суток после выхода обновления. Мониторинг производительности: постоянный мониторинг работы сервера и базы данных; оптимизация производительности системы при необходимости. Документальная поддержка: обновление документации по использованию программы после выхода и установки обновлений ПО; разработка инструкций и рекомендаций для пользователей Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Цели предоставления сертификата технической поддержки - Целью технической поддержки является обеспечение бесперебойной эксплуатации программного обеспечения «АСУР», минимизация рисков сбоев и нарушений в работе системы, своевременное устранение неисправностей и решение возникающих вопросов пользователей. Срок оказания технической поддержки с 01.07.2026 года по 01.07.2027 года включительно - - Значение характеристики не может изменяться участником закупки - Режимы оказания технической поддержки - Стандартный режим (рабочие дни): Время предоставления поддержки: с понедельника по пятницу с 09:00 до 18:00 по московскому времени; Срок реакции на обращение: не позднее 4 часов с момента получения заявки; Решение срочных вопросов: не более 24 часов. Экстренный режим (внеплановые инциденты): Круглосуточная доступность службы техподдержки в случае критического сбоя, влияющего на работу всей системы; Максимальное время реакции на экстренные обращения — 30 минут; Необходимость разрешения проблемы — в течение 12 часов. Методы взаимодействия с пользователями Телефонная связь: Для срочной связи предусмотрена горячая линия. Телефонные консультации проводятся в рабочее время стандартного режима. Телефон технической поддержки должен быть прописан и закреплен в сертификате технической поддержки. Электронная почта: Пользователи могут отправлять запросы на электронный адрес службы поддержки. Оперативность ответа на электронные письма — не более 4 часов. Электронная почта технической поддержки должна быть прописана и закреплена в сертификате технической поддержки. Требования к квалификации специалистов техподдержки Специалисты, предоставляющие техническую поддержку, должны обладать следующим набором компетенций: опыт работы с аналогичными программными комплексами; глубокие знания архитектуры и функционала программы «АСУР»; навыки диагностики и устранения ошибок в программном обеспечении; коммуникабельность и умение грамотно консультировать пользователей.» - - Значение характеристики не может изменяться участником закупки - Состав предоставляемых услуг - Техническая поддержка включает следующие виды услуг: Первичная диагностика проблем: анализ сообщений об ошибках, поступающих от пользователей; идентификация причины возникновения проблемы. Устранение неисправностей: исправление ошибок в коде программы; настройка конфигурации системы для восстановления её работоспособности. Консультативные услуги: ответы на запросы пользователей по вопросам использования программы; инструктаж по решению технических вопросов. Обновление ПО: выпуск обновлений программного обеспечения для исправления обнаруженных багов и добавления новых функций; установку обновлений на сервер заказчика в течении суток после выхода обновления. Мониторинг производительности: постоянный мониторинг работы сервера и базы данных; оптимизация производительности системы при необходимости. Документальная поддержка: обновление документации по использованию программы после выхода и установки обновлений ПО; разработка инструкций и рекомендаций для пользователей - - Значение характеристики не может изменяться участником закупки

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

Цели предоставления сертификата технической поддержки - Целью технической поддержки является обеспечение бесперебойной эксплуатации программного обеспечения «АСУР», минимизация рисков сбоев и нарушений в работе системы, своевременное устранение неисправностей и решение возникающих вопросов пользователей. Срок оказания технической поддержки с 01.07.2026 года по 01.07.2027 года включительно - - Значение характеристики не может изменяться участником закупки

Режимы оказания технической поддержки - Стандартный режим (рабочие дни): Время предоставления поддержки: с понедельника по пятницу с 09:00 до 18:00 по московскому времени; Срок реакции на обращение: не позднее 4 часов с момента получения заявки; Решение срочных вопросов: не более 24 часов. Экстренный режим (внеплановые инциденты): Круглосуточная доступность службы техподдержки в случае критического сбоя, влияющего на работу всей системы; Максимальное время реакции на экстренные обращения — 30 минут; Необходимость разрешения проблемы — в течение 12 часов. Методы взаимодействия с пользователями Телефонная связь: Для срочной связи предусмотрена горячая линия. Телефонные консультации проводятся в рабочее время стандартного режима. Телефон технической поддержки должен быть прописан и закреплен в сертификате технической поддержки. Электронная почта: Пользователи могут отправлять запросы на электронный адрес службы поддержки. Оперативность ответа на электронные письма — не более 4 часов. Электронная почта технической поддержки должна быть прописана и закреплена в сертификате технической поддержки. Требования к квалификации специалистов техподдержки Специалисты, предоставляющие техническую поддержку, должны обладать следующим набором компетенций: опыт работы с аналогичными программными комплексами; глубокие знания архитектуры и функционала программы «АСУР»; навыки диагностики и устранения ошибок в программном обеспечении; коммуникабельность и умение грамотно консультировать пользователей.» - - Значение характеристики не может изменяться участником закупки

Состав предоставляемых услуг - Техническая поддержка включает следующие виды услуг: Первичная диагностика проблем: анализ сообщений об ошибках, поступающих от пользователей; идентификация причины возникновения проблемы. Устранение неисправностей: исправление ошибок в коде программы; настройка конфигурации системы для восстановления её работоспособности. Консультативные услуги: ответы на запросы пользователей по вопросам использования программы; инструктаж по решению технических вопросов. Обновление ПО: выпуск обновлений программного обеспечения для исправления обнаруженных багов и добавления новых функций; установку обновлений на сервер заказчика в течении суток после выхода обновления. Мониторинг производительности: постоянный мониторинг работы сервера и базы данных; оптимизация производительности системы при необходимости. Документальная поддержка: обновление документации по использованию программы после выхода и установки обновлений ПО; разработка инструкций и рекомендаций для пользователей - - Значение характеристики не может изменяться участником закупки

- 26.20.12.130 - Поставка серверной инфраструктуры для обеспечения функционирования модуля управления деятельностью учреждения Общие требования серверного оборудования, поставляемое в целях функционирования модуля управления деятельностью учреждения Каждый сервер должен быть новым, не бывшим в эксплуатации, и включен в реестр Российской продукции (реестровая запись должна быть подтверждена на дату поставки) Конструктивное исполнение Каждый сервер должен: быть выполнен в стоечном исполнении для установки в 19-дюймовую стойку; иметь высоту не более 2U; комплектоваться направляющими/крепежом для монтажа в стойку и кабельным органайзером; иметь защитную лицевую панель с замком и ключами; иметь на передней панели не менее 2 портов USB 3.0 и не менее 1 порта VGA; иметь не менее 8 фронтальных отсеков для накопителей формата 2.5"/3.5" с горячей заменой Система охлаждения и электропитания Каждый сервер должен быть оснащен: штатной системой охлаждения, обеспечивающей стабильную работу установленной конфигурации (включая графический ускоритель); не менее чем 2 блоками питания мощностью не менее 3200 Вт каждый - Штука - 1,00 - 36 000 000,00 - 36 000 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Общие требования серверного оборудования, поставляемое в целях функционирования модуля управления деятельностью учреждения Каждый сервер должен быть новым, не бывшим в эксплуатации, и включен в реестр Российской продукции (реестровая запись должна быть подтверждена на дату поставки) Значение характеристики не может изменяться участником закупки Конструктивное исполнение Каждый сервер должен: быть выполнен в стоечном исполнении для установки в 19-дюймовую стойку; иметь высоту не более 2U; комплектоваться направляющими/крепежом для монтажа в стойку и кабельным органайзером; иметь защитную лицевую панель с замком и ключами; иметь на передней панели не менее 2 портов USB 3.0 и не менее 1 порта VGA; иметь не менее 8 фронтальных отсеков для накопителей формата 2.5"/3.5" с горячей заменой Значение характеристики не может изменяться участником закупки Система охлаждения и электропитания Каждый сервер должен быть оснащен: штатной системой охлаждения, обеспечивающей стабильную работу установленной конфигурации (включая графический ускоритель); не менее чем 2 блоками питания мощностью не менее 3200 Вт каждый Значение характеристики не может изменяться участником закупки Процессорная подсистема Каждый сервер должен быть укомплектован: не менее чем 2 установленными процессорами; каждый процессор: не менее 24 ядер, не менее 48 потоков, базовая частота не менее 2,9 ГГц, кэш-память не менее 60 МБ; поддержка 64-разрядных вычислений и технологий энергосбережения/управления питанием под нагрузкой Значение характеристики не может изменяться участником закупки Гарантия и сервис Поставляемые сервера должны иметь: гарантийная поддержка не менее 3 лет; уровень сервиса: выезд инженера и начало работ на следующий рабочий день после регистрации обращения Значение характеристики не может изменяться участником закупки Интерфейсы расширения и внутренние интерфейсы Каждый сервер должен обеспечивать: наличие выделенного порта удаленного управления (RJ-45); наличие внутренних интерфейсов для подключения системных M.2 NVMe-накопителей; наличие интерфейсов/слотов расширения, достаточных для установки: дискретного RAID-контроллера; сетевых адаптеров 10/25 Гбит/с; не менее одного графического ускорителя форм-фактора dual-width Значение характеристики не может изменяться участником закупки Дисковая подсистема Каждый сервер должен быть оснащен: дискретным RAID-контроллером с кэш-памятью не менее 4 ГБ и защитой кэша при отключении питания; поддержкой RAID не ниже: 0, 1, 5, 6, 10, 50, 60; системным диском: не менее 2 ? 960 ГБ M.2 NVMe SSD; дисковой группой HDD: не менее 2 ? 16 ТБ SAS, 7200 rpm; дисковой группой SSD SAS: не менее 2 ? 3,84 ТБ; дисковой группой SSD NVMe: не менее 2 ? 3,84 ТБ; поддержкой S.M.A.R.T., горячей замены дисков в фронтальных отсеках, автоматического восстановления после сбоя питания Значение характеристики не может изменяться участником закупки Графические ускорители Каждый сервер должен быть оснащен не менее чем 1 профессиональным графическим ускорителем со следующими характеристиками: объем видеопамяти не менее 80 ГБ; тип памяти не ниже HBM2e; интерфейс подключения PCI Express x16 Gen4; теплопакет ускорителя не более 300 Вт Значение характеристики не может изменяться участником закупки Сетевые интерфейсы и внешние порты Каждый сервер должен иметь: не менее 2 портов 10 Гбит/с RJ-45; не менее 2 портов 10/25 Гбит/с (SFP28); выделенный порт удаленного управления (RJ-45); не менее 1 порта VGA (задняя панель); внешние USB-порты, включая не менее 2 портов USB 3.0 Значение характеристики не может изменяться участником закупки Оперативная память Каждый сервер должен иметь: не менее 32 слотов ОЗУ; установленную память типа DDR5 Registered ECC; суммарный установленный объем ОЗУ не менее 512 ГБ; эффективную частоту модулей не менее 5600 МГц (с учетом фактического режима работы платформы) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Общие требования серверного оборудования, поставляемое в целях функционирования модуля управления деятельностью учреждения - Каждый сервер должен быть новым, не бывшим в эксплуатации, и включен в реестр Российской продукции (реестровая запись должна быть подтверждена на дату поставки) - - Значение характеристики не может изменяться участником закупки - Конструктивное исполнение - Каждый сервер должен: быть выполнен в стоечном исполнении для установки в 19-дюймовую стойку; иметь высоту не более 2U; комплектоваться направляющими/крепежом для монтажа в стойку и кабельным органайзером; иметь защитную лицевую панель с замком и ключами; иметь на передней панели не менее 2 портов USB 3.0 и не менее 1 порта VGA; иметь не менее 8 фронтальных отсеков для накопителей формата 2.5"/3.5" с горячей заменой - - Значение характеристики не может изменяться участником закупки - Система охлаждения и электропитания - Каждый сервер должен быть оснащен: штатной системой охлаждения, обеспечивающей стабильную работу установленной конфигурации (включая графический ускоритель); не менее чем 2 блоками питания мощностью не менее 3200 Вт каждый - - Значение характеристики не может изменяться участником закупки - Процессорная подсистема - Каждый сервер должен быть укомплектован: не менее чем 2 установленными процессорами; каждый процессор: не менее 24 ядер, не менее 48 потоков, базовая частота не менее 2,9 ГГц, кэш-память не менее 60 МБ; поддержка 64-разрядных вычислений и технологий энергосбережения/управления питанием под нагрузкой - - Значение характеристики не может изменяться участником закупки - Гарантия и сервис - Поставляемые сервера должны иметь: гарантийная поддержка не менее 3 лет; уровень сервиса: выезд инженера и начало работ на следующий рабочий день после регистрации обращения - - Значение характеристики не может изменяться участником закупки - Интерфейсы расширения и внутренние интерфейсы - Каждый сервер должен обеспечивать: наличие выделенного порта удаленного управления (RJ-45); наличие внутренних интерфейсов для подключения системных M.2 NVMe-накопителей; наличие интерфейсов/слотов расширения, достаточных для установки: дискретного RAID-контроллера; сетевых адаптеров 10/25 Гбит/с; не менее одного графического ускорителя форм-фактора dual-width - - Значение характеристики не может изменяться участником закупки - Дисковая подсистема - Каждый сервер должен быть оснащен: дискретным RAID-контроллером с кэш-памятью не менее 4 ГБ и защитой кэша при отключении питания; поддержкой RAID не ниже: 0, 1, 5, 6, 10, 50, 60; системным диском: не менее 2 ? 960 ГБ M.2 NVMe SSD; дисковой группой HDD: не менее 2 ? 16 ТБ SAS, 7200 rpm; дисковой группой SSD SAS: не менее 2 ? 3,84 ТБ; дисковой группой SSD NVMe: не менее 2 ? 3,84 ТБ; поддержкой S.M.A.R.T., горячей замены дисков в фронтальных отсеках, автоматического восстановления после сбоя питания - - Значение характеристики не может изменяться участником закупки - Графические ускорители - Каждый сервер должен быть оснащен не менее чем 1 профессиональным графическим ускорителем со следующими характеристиками: объем видеопамяти не менее 80 ГБ; тип памяти не ниже HBM2e; интерфейс подключения PCI Express x16 Gen4; теплопакет ускорителя не более 300 Вт - - Значение характеристики не может изменяться участником закупки - Сетевые интерфейсы и внешние порты - Каждый сервер должен иметь: не менее 2 портов 10 Гбит/с RJ-45; не менее 2 портов 10/25 Гбит/с (SFP28); выделенный порт удаленного управления (RJ-45); не менее 1 порта VGA (задняя панель); внешние USB-порты, включая не менее 2 портов USB 3.0 - - Значение характеристики не может изменяться участником закупки - Оперативная память - Каждый сервер должен иметь: не менее 32 слотов ОЗУ; установленную память типа DDR5 Registered ECC; суммарный установленный объем ОЗУ не менее 512 ГБ; эффективную частоту модулей не менее 5600 МГц (с учетом фактического режима работы платформы) - - Значение характеристики не может изменяться участником закупки

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

Общие требования серверного оборудования, поставляемое в целях функционирования модуля управления деятельностью учреждения - Каждый сервер должен быть новым, не бывшим в эксплуатации, и включен в реестр Российской продукции (реестровая запись должна быть подтверждена на дату поставки) - - Значение характеристики не может изменяться участником закупки

Конструктивное исполнение - Каждый сервер должен: быть выполнен в стоечном исполнении для установки в 19-дюймовую стойку; иметь высоту не более 2U; комплектоваться направляющими/крепежом для монтажа в стойку и кабельным органайзером; иметь защитную лицевую панель с замком и ключами; иметь на передней панели не менее 2 портов USB 3.0 и не менее 1 порта VGA; иметь не менее 8 фронтальных отсеков для накопителей формата 2.5"/3.5" с горячей заменой - - Значение характеристики не может изменяться участником закупки

Система охлаждения и электропитания - Каждый сервер должен быть оснащен: штатной системой охлаждения, обеспечивающей стабильную работу установленной конфигурации (включая графический ускоритель); не менее чем 2 блоками питания мощностью не менее 3200 Вт каждый - - Значение характеристики не может изменяться участником закупки

Процессорная подсистема - Каждый сервер должен быть укомплектован: не менее чем 2 установленными процессорами; каждый процессор: не менее 24 ядер, не менее 48 потоков, базовая частота не менее 2,9 ГГц, кэш-память не менее 60 МБ; поддержка 64-разрядных вычислений и технологий энергосбережения/управления питанием под нагрузкой - - Значение характеристики не может изменяться участником закупки

Гарантия и сервис - Поставляемые сервера должны иметь: гарантийная поддержка не менее 3 лет; уровень сервиса: выезд инженера и начало работ на следующий рабочий день после регистрации обращения - - Значение характеристики не может изменяться участником закупки

Интерфейсы расширения и внутренние интерфейсы - Каждый сервер должен обеспечивать: наличие выделенного порта удаленного управления (RJ-45); наличие внутренних интерфейсов для подключения системных M.2 NVMe-накопителей; наличие интерфейсов/слотов расширения, достаточных для установки: дискретного RAID-контроллера; сетевых адаптеров 10/25 Гбит/с; не менее одного графического ускорителя форм-фактора dual-width - - Значение характеристики не может изменяться участником закупки

Дисковая подсистема - Каждый сервер должен быть оснащен: дискретным RAID-контроллером с кэш-памятью не менее 4 ГБ и защитой кэша при отключении питания; поддержкой RAID не ниже: 0, 1, 5, 6, 10, 50, 60; системным диском: не менее 2 ? 960 ГБ M.2 NVMe SSD; дисковой группой HDD: не менее 2 ? 16 ТБ SAS, 7200 rpm; дисковой группой SSD SAS: не менее 2 ? 3,84 ТБ; дисковой группой SSD NVMe: не менее 2 ? 3,84 ТБ; поддержкой S.M.A.R.T., горячей замены дисков в фронтальных отсеках, автоматического восстановления после сбоя питания - - Значение характеристики не может изменяться участником закупки

Графические ускорители - Каждый сервер должен быть оснащен не менее чем 1 профессиональным графическим ускорителем со следующими характеристиками: объем видеопамяти не менее 80 ГБ; тип памяти не ниже HBM2e; интерфейс подключения PCI Express x16 Gen4; теплопакет ускорителя не более 300 Вт - - Значение характеристики не может изменяться участником закупки

Сетевые интерфейсы и внешние порты - Каждый сервер должен иметь: не менее 2 портов 10 Гбит/с RJ-45; не менее 2 портов 10/25 Гбит/с (SFP28); выделенный порт удаленного управления (RJ-45); не менее 1 порта VGA (задняя панель); внешние USB-порты, включая не менее 2 портов USB 3.0 - - Значение характеристики не может изменяться участником закупки

Оперативная память - Каждый сервер должен иметь: не менее 32 слотов ОЗУ; установленную память типа DDR5 Registered ECC; суммарный установленный объем ОЗУ не менее 512 ГБ; эффективную частоту модулей не менее 5600 МГц (с учетом фактического режима работы платформы) - - Значение характеристики не может изменяться участником закупки

- 26.20.12.130 - Предоставление доступа к функциональному модулю управления деятельностью учреждения Цели внедрения модуля Целями внедрения модуля управления деятельностью учреждения являются повышение эффективности управления внутренними процессами Заказчика, формирование единого цифрового пространства для взаимодействия структурных подразделений, обеспечение централизованного учета данных, а также сокращение сроков обработки информации, документов, поручений и управленческих решений. Внедрение модуля должна обеспечить унификацию и формализацию бизнес-процессов, повышение прозрачности исполнения задач и поручений, снижение зависимости от разрозненных информационных ресурсов и ручных операций, а также повышение качества контроля сроков, статусов и результатов деятельности подразделений. Дополнительными целями внедрения являются: обеспечение единой точки входа пользователей в модули системы; создание сквозного контура работы с данными, документами, задачами, отчетностью и интеграциями; автоматизация функциональных процессов подразделений Заказчика; повышение достоверности, полноты и актуальности данных; обеспечение оперативного получения аналитической и управленческой отчетности; обеспечение возможности масштабирования системы за счет подключения новых модулей, сервисов и интеграций; создание технологической основы для дальнейшего развития цифровых сервисов Заказчика Раздел «Реестр событий информационной безопасности» 2 Контур реагирования на инциденты Раздел должен обеспечивать управление процессом реагирования на инциденты информационной безопасности. Данная функциональность предназначена для минимизации последствий утечек и обеспечения соблюдения регламентов реагирования. Функциональность должна включать: назначение ответственных за обработку инцидентов; управление статусами инцидентов (новый, в работе, закрыт и др.); контроль сроков реагирования; фиксацию действий по устранению инцидента; автоматическое уведомление участников процесса; контроль исполнения регламентов реагирования; эскалацию критических инцидентов; формирование отчетов по реагированию; поддержку маршрутов согласования решений. Мониторинг и отчетность Раздел должен обеспечивать мониторинг состояния информационной безопасности, уровня рисков утечки информации и ключевых показателей эффективности. Данная функциональность предназначена для предоставления актуальной информации руководству и ответственным подразделениям. Функциональность должна включать: формирование дашбордов по инцидентам ИБ; мониторинг уровня угроз и рисков утечки; контроль количества и динамики инцидентов; анализ эффективности мер защиты; выявление критических отклонений; контроль времени реагирования на инциденты; формирование регламентированной отчетности; выгрузку отчетов в Excel и PDF; формирование аналитических срезов по типам инцидентов, подразделениям, пользователям и периодам Результаты внедрения модуля 2 Дополнительно результатом внедрения системы должно стать формирование единого подхода к работе пользователей с цифровыми сервисами Заказчика, включая единые правила доступа, маршрутизации, уведомлений, журналирования действий, формирования документов и использования общих справочников. В результате внедрения системы должны быть обеспечены условия для последующей промышленной эксплуатации, сопровождения, развития функциональности и масштабирования системы в соответствии с потребностями Заказчика - Штука - 1,00 - 47 500 000,00 - 47 500 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Цели внедрения модуля Целями внедрения модуля управления деятельностью учреждения являются повышение эффективности управления внутренними процессами Заказчика, формирование единого цифрового пространства для взаимодействия структурных подразделений, обеспечение централизованного учета данных, а также сокращение сроков обработки информации, документов, поручений и управленческих решений. Внедрение модуля должна обеспечить унификацию и формализацию бизнес-процессов, повышение прозрачности исполнения задач и поручений, снижение зависимости от разрозненных информационных ресурсов и ручных операций, а также повышение качества контроля сроков, статусов и результатов деятельности подразделений. Дополнительными целями внедрения являются: обеспечение единой точки входа пользователей в модули системы; создание сквозного контура работы с данными, документами, задачами, отчетностью и интеграциями; автоматизация функциональных процессов подразделений Заказчика; повышение достоверности, полноты и актуальности данных; обеспечение оперативного получения аналитической и управленческой отчетности; обеспечение возможности масштабирования системы за счет подключения новых модулей, сервисов и интеграций; создание технологической основы для дальнейшего развития цифровых сервисов Заказчика Значение характеристики не может изменяться участником закупки Раздел «Реестр событий информационной безопасности» 2 Контур реагирования на инциденты Раздел должен обеспечивать управление процессом реагирования на инциденты информационной безопасности. Данная функциональность предназначена для минимизации последствий утечек и обеспечения соблюдения регламентов реагирования. Функциональность должна включать: назначение ответственных за обработку инцидентов; управление статусами инцидентов (новый, в работе, закрыт и др.); контроль сроков реагирования; фиксацию действий по устранению инцидента; автоматическое уведомление участников процесса; контроль исполнения регламентов реагирования; эскалацию критических инцидентов; формирование отчетов по реагированию; поддержку маршрутов согласования решений. Мониторинг и отчетность Раздел должен обеспечивать мониторинг состояния информационной безопасности, уровня рисков утечки информации и ключевых показателей эффективности. Данная функциональность предназначена для предоставления актуальной информации руководству и ответственным подразделениям. Функциональность должна включать: формирование дашбордов по инцидентам ИБ; мониторинг уровня угроз и рисков утечки; контроль количества и динамики инцидентов; анализ эффективности мер защиты; выявление критических отклонений; контроль времени реагирования на инциденты; формирование регламентированной отчетности; выгрузку отчетов в Excel и PDF; формирование аналитических срезов по типам инцидентов, подразделениям, пользователям и периодам Значение характеристики не может изменяться участником закупки Результаты внедрения модуля 2 Дополнительно результатом внедрения системы должно стать формирование единого подхода к работе пользователей с цифровыми сервисами Заказчика, включая единые правила доступа, маршрутизации, уведомлений, журналирования действий, формирования документов и использования общих справочников. В результате внедрения системы должны быть обеспечены условия для последующей промышленной эксплуатации, сопровождения, развития функциональности и масштабирования системы в соответствии с потребностями Заказчика Значение характеристики не может изменяться участником закупки Общие требования к системе Назначение, режимы функционирования Система предназначена для автоматизации внутренних процессов Заказчика, информационной поддержки деятельности структурных подразделений, централизованного ведения данных, документов, задач, поручений, справочников и карточек учета, а также для формирования отчетности и обеспечения межмодульного взаимодействия. Система должна функционировать в режиме многопользовательской работы с обеспечением одновременного доступа пользователей к предусмотренным функциональным возможностям в пределах их полномочий. Единая точка входа и единая авторизация. Доступ пользователей к Системе должен быть организован по принципу единой точки входа с последующим предоставлением доступа к доступным функциональным модулям в соответствии с ролями и полномочиями пользователя. При внедрении системы должны быть предусмотрены единые механизмы идентификации и аутентификации пользователей, обеспечивающие централизованный доступ к системе без необходимости использования отдельных механизмов входа для каждого модуля. Организация доступа к системе должна учитывать корпоративную модель управления учетными записями пользователей, используемую в ИТ-инфраструктуре Заказчика, включая подходы к идентификации и авторизации. Модульность и масштабирование. Система должна строиться по модульному принципу, предусматривающему возможность независимого подключения, настройки, развития и сопровождения отдельных функциональных модулей в рамках единого системного контура. Архитектура системы должна обеспечивать возможность поэтапного расширения состава модулей, функций, пользовательских сценариев, отчетных форм, интеграций и сервисов без необходимости переработки уже внедренных компонентов. Система должна обеспечивать возможность масштабирования по количеству пользователей, составу автоматизируемых подразделений, объему обрабатываемых данных, количеству подключаемых модулей и числу интеграционных взаимодействий Значение характеристики не может изменяться участником закупки Требования к структуре модулей системы Общая архитектура. Архитектура системы должна обеспечивать функционирование единой цифровой среды, объединяющей функциональные модули, общие сервисы, механизмы хранения и обработки данных, средства управления доступом, инструменты журналирования, уведомления, отчетности и интеграционного взаимодействия. Архитектурные решения должны обеспечивать целостность системы, согласованность работы функциональных модулей, возможность централизованного администрирования, а также условия для последующего развития, адаптации и расширения функциональности без нарушения общей логики работы системы. Развитие функционала должно предусматривать единые подходы к организации пользовательского доступа, обработке данных, использованию общих справочников, хранению документов и истории изменений, а также к взаимодействию между модулями и внешними системами. Состав модулей и связи между ними. Структура системы должна предусматривать наличие функциональных модулей, автоматизирующих отдельные направления деятельности Заказчика, при сохранении их работы в рамках единого информационного контура. Состав модулей определяется требованиями настоящего Технического задания и может включать модули, предназначенные для автоматизации процессов пресс-службы, безопасности и гражданской обороны, учета персональных данных и согласий, административного управления, управления комплектацией и ремонта, а также иные модули, предусмотренные проектными решениями и этапами внедрения. Связи между модулями должны обеспечивать возможность обмена данными, использования единых справочников, передачи статусов, задач, документов, уведомлений и иных сущностей, необходимых для сквозного выполнения процессов и формирования консолидированной отчетности Значение характеристики не может изменяться участником закупки Контур развертывания Развертывание системы должно осуществляться на контуре Заказчика. Состав используемых сред, порядок развертывания, размещения компонентов системы, хранения данных, настройки серверной части, доступа пользователей и эксплуатации системы определяются с учетом ИТ-инфраструктуры Заказчика, требований информационной безопасности, эксплуатационных ограничений и проектных решений, принимаемых в рамках внедрения. При развертывании системы на контуре Заказчика должны быть обеспечены условия для функционирования пользовательской, серверной, интеграционной и сервисной составляющих системы. Общие сервисы. В структуре системы должны использоваться общие сервисы, обеспечивающие единые механизмы работы функциональных модулей и пользователей в рамках всей системы. К общим сервисам относятся, в частности, сервисы аутентификации и авторизации, ведения справочников, поиска, журналирования действий, хранения вложений и документов, формирования уведомлений, маршрутизации процессов, формирования отчетности, а также сервисы интеграционного взаимодействия. Использование общих сервисов должно обеспечивать единообразие пользовательских сценариев, повторное использование функциональных механизмов, снижение дублирования решений между модулями и упрощение сопровождения и развития Системы Значение характеристики не может изменяться участником закупки Перечень разделов В состав модуля управления деятельностью учреждения должны входить разделы, обеспечивающие автоматизацию основных направлений деятельности Заказчика в рамках единого информационного пространства. Перечень разделов модуля управления деятельностью учреждения определяется настоящим Техническим заданием и включает: раздел «Работа ПИДК»; раздел «Потребности ГКО»; раздел «База знаний»; раздел «Дашборд и средства навигации между модулями»; раздел «Пресс-служба»; раздел «Безопасность и гражданская оборона»; раздел «Управление информационных технологий»; раздел «Административное управление»; раздел «Управление закупок»; раздел «Управление комплектации и ремонта»; раздел «Реестр событий информационной безопасности»; раздел «Интеграция со смежными системами»; иные разделы, предусмотренные этапами внедрения, проектными решениями и потребностями Заказчика. Требования к подключению новых разделов. Функциональные разделы модуля управления деятельностью учреждения должны внедряться как составные части единой системы с обеспечением единых подходов к пользовательскому доступу, обработке данных, ведению справочников, журналированию действий, хранению документов, формированию отчетности и интеграционному взаимодействию. Каждый функциональный раздел должен обеспечивать выполнение предусмотренных для него задач, поддержку соответствующих пользовательских сценариев, возможность работы в рамках установленной ролевой модели и взаимодействие с иными разделами и модулями Системы в части передачи и получения данных, статусов, документов, уведомлений и иных сущностей Значение характеристики не может изменяться участником закупки Ролевая модель В Системе должна быть реализована ролевая модель доступа, обеспечивающая предоставление пользователям прав в зависимости от их функциональных обязанностей, участия в бизнес-процессах, принадлежности к структурным подразделениям и уровня ответственности. Ролевая модель должна обеспечивать возможность назначения пользователям одной или нескольких ролей, определяющих состав доступных функций, данных, документов, отчетности и действий в системе. Состав ролей, их полномочия и правила назначения должны определяться в рамках настройки системы с учетом требований Заказчика, организационной структуры и особенностей автоматизируемых процессов. Разграничение доступа. Система должна обеспечивать разграничение доступа к функциональным возможностям, данным, документам, карточкам учета, задачам, отчетности и иным объектам системы в соответствии с назначенными ролями и полномочиями пользователей. Разграничение доступа должно учитывать не только роль пользователя, но и его принадлежность к подразделению, участие в конкретном процессе, статус исполнителя, согласующего или администратора, а также иные параметры, необходимые для ограничения доступа к информации и действиям в системе. Доступ к данным и функциям системы должен предоставляться по принципу достаточности полномочий, необходимому для выполнения пользователем его служебных задач Значение характеристики не может изменяться участником закупки Делегирование, замещение, соисполнители В Системе должна быть предусмотрена возможность делегирования отдельных полномочий, временного замещения пользователей, а также назначения соисполнителей в рамках задач, поручений, согласований и иных процессов, где требуется участие нескольких пользователей. Механизмы делегирования и замещения должны обеспечивать передачу прав и обязанностей на установленный период времени либо в пределах определенного процесса с учетом ограничений, заданных ролевой моделью и правилами доступа. При назначении соисполнителей система должна обеспечивать возможность распределения задач между несколькими участниками процесса, фиксации их роли в исполнении, контроля сроков и учета действий каждого участника. Администрирование ролей и журналирование изменений прав. Система должна обеспечивать возможность централизованного администрирования ролей, полномочий и параметров доступа пользователей. Должна быть предусмотрена возможность назначения, изменения, временного предоставления, ограничения и прекращения прав доступа пользователей в соответствии с установленными правилами администрирования. Изменения в составе ролей, правах пользователей, делегированных полномочиях и настройках доступа должны фиксироваться в журнале системы с указанием сведений о выполненном действии, пользователе, инициировавшем изменение, дате и времени выполнения операции Значение характеристики не может изменяться участником закупки Требования к интерфейсу пользователя Стартовая страница. В Системе должна быть предусмотрена стартовая страница, обеспечивающая пользователю удобный доступ к основным функциональным модулям, разделам, сервисам, уведомлениям и элементам навигации. Стартовая страница должна использоваться как единая точка входа в систему после прохождения авторизации и обеспечивать отображение доступных пользователю разделов в зависимости от его роли, полномочий и настроек доступа. На стартовой странице может предусматриваться размещение информационных блоков, виджетов, индикаторов, уведомлений, ссылок на модули, разделы, а также иных элементов, необходимых для организации быстрого перехода к основным пользовательским сценариям. Навигация. Интерфейс Системы должен обеспечивать понятную и единообразную навигацию между функциональными модулями, разделами, карточками, справочников, задачами, документами и иными объектами системы. Навигационные элементы должны обеспечивать пользователю быстрый переход к доступным разделам системы, возможность возврата к предыдущим экранам, переход на стартовую страницу, а также доступ к основным операциям в рамках текущего сценария работы. Навигация должна учитывать состав доступных пользователю модулей и функций, а также обеспечивать удобство работы при большом количестве функциональных разделов системы Значение характеристики не может изменяться участником закупки Требования к интерфейсу пользователя 2 Адаптивность интерфейса. Интерфейс Системы должен обеспечивать корректное отображение и использование основных функциональных возможностей при работе с различных типов пользовательских устройств, включая персональные компьютеры, планшеты и мобильные устройства, в объеме, предусмотренном проектными решениями и требованиями Заказчика. Адаптивность интерфейса должна обеспечивать сохранение логики пользовательских сценариев, доступности основных элементов управления и читаемости отображаемой информации при изменении разрешения экрана, размеров рабочей области и типа используемого устройства. Единые UI?паттерны. Интерфейс Системы должен строиться с использованием единых UI-паттернов, обеспечивающих единообразное отображение элементов управления, карточек, справочников, форм ввода, уведомлений, фильтров, статусов, маршрутов согласования, отчетных блоков и иных компонентов пользовательского интерфейса. Использование единых UI-паттернов должно обеспечивать предсказуемость пользовательских действий, снижение времени на освоение системы, единый визуальный подход к работе в различных функциональных модулях, а также упрощение дальнейшего развития и сопровождения интерфейса Системы Значение характеристики не может изменяться участником закупки Требования к ведению справочников и классификаторов Единые корпоративные справочники. В Системе должно быть предусмотрено ведение единых корпоративных справочников и классификаторов, используемых функциональными модулями системы для обеспечения единообразия данных, унификации подходов к учету и исключения дублирования сведений. К единым корпоративным справочникам могут относиться справочники организационной структуры, подразделений, должностей, сотрудников, ролей, типов документов, статусов, категорий объектов учета, контрагентов, видов операций и иные справочники, необходимые для функционирования системы. Использование единых корпоративных справочников должно обеспечивать согласованность данных между модулями и разделами Системы, поддержку сквозных процессов, корректность фильтрации, поиска, отчетности и интеграционного обмена. Версионность справочников и контроль изменений. Система должна обеспечивать возможность фиксации изменений, вносимых в справочники и классификаторы, с сохранением истории таких изменений в объеме, необходимом для обеспечения прослеживаемости и контроля актуальности данных. При необходимости должна быть предусмотрена возможность ведения версий отдельных справочников, контроля даты вступления изменений в силу, а также фиксации сведений о пользователе, внесшем изменение, дате и времени изменения. Изменения, вносимые в справочники и классификаторы, должны осуществляться в контролируемом порядке с учетом установленных полномочий пользователей и правил администрирования Значение характеристики не может изменяться участником закупки Требования к ведению справочников и классификаторов 2 Импорт и экспорт справочников. В Системе должна быть предусмотрена возможность импорта и экспорта справочников и классификаторов в объеме, необходимом для первичного заполнения, актуализации данных, переноса сведений и обеспечения интеграционного взаимодействия. Импорт и экспорт справочников должны обеспечивать загрузку и выгрузку данных в распространенных электронных форматах, используемых в деятельности Заказчика, с учетом требований к структуре данных, полноте реквизитов и контролю корректности загружаемой информации. Порядок импорта, экспорта, обновления и синхронизации справочников определяется проектными решениями, настройками системы и правилами ведения нормативно-справочной информации Значение характеристики не может изменяться участником закупки Требования к поиску, фильтрации и сортировке данных Полнотекстовый поиск. В Системе должна быть предусмотрена возможность полнотекстового поиска по данным, документам, карточкам, справочников и иным объектам, в отношении которых такая функциональность необходима для реализации пользовательских сценариев. Полнотекстовый поиск должен обеспечивать возможность поиска по наименованиям, реквизитам, текстовому содержанию документов, комментариям, описаниям и иным доступным пользователю данным в пределах его полномочий. Результаты поиска должны отображаться в удобной для пользователя форме с возможностью последующего перехода к найденным объектам, уточнения поискового запроса и применения дополнительных условий отбора. Контекстные фильтры по реквизитам. В Системе должна быть предусмотрена возможность применения контекстных фильтров по реквизитам объектов, документов, карточек, записей справочников, задач, поручений и иных сущностей системы. Фильтрация должна обеспечивать отбор данных по значениям атрибутов, статусам, датам, подразделениям, ответственным лицам, типам объектов, категориям, срокам и иным реквизитам, используемым в соответствующем функциональном модуле. Состав доступных фильтров должен определяться особенностями конкретного раздела системы, характером отображаемых данных и правами пользователя. Сохраненные представления. В Системе должна быть предусмотрена возможность сохранения пользовательских представлений данных, включая наборы фильтров, параметры сортировки, состав и порядок отображаемых колонок, а также иные настройки экранных форм и справочников, если это предусмотрено функциональностью соответствующего модуля. Сохраненные представления должны обеспечивать удобство повторного доступа пользователя к часто используемым вариантам отображения данных и повышать эффективность работы со справочниками, списками, журналами и отчетными представлениями. Порядок создания, изменения, использования и удаления сохраненных представлений определяется функциональными возможностями системы, настройками доступа пользователя Значение характеристики не может изменяться участником закупки Требования к журналированию действий пользователей Аудит?лог по ключевым сущностям. В Системе должно быть предусмотрено журналирование действий пользователей и системных событий по ключевым сущностям, используемым в функциональных модулях системы. К таким сущностям могут относиться документы, карточки объектов учета, поручения, задачи, записи реестров, справочники, учетные записи, согласования, статусы, маршруты, вложения, отчеты и иные объекты, изменение которых требует фиксации в целях контроля, прослеживаемости и последующего анализа. Аудит-лог должен обеспечивать фиксацию сведений о выполненном действии, объекте, пользователе, дате и времени операции, а также иных параметров, необходимых для понимания характера выполненного изменения. Неизменяемость и защищенность журнала. Журнал действий пользователей должен храниться в системе с обеспечением его целостности, защищенности и недопустимости несанкционированного изменения или удаления записей. Доступ к просмотру, выгрузке и администрированию журналов должен предоставляться ограниченному кругу пользователей в соответствии с установленными ролями и полномочиями. Механизмы хранения и защиты журналов должны обеспечивать возможность использования содержащихся в них сведений для внутреннего контроля, анализа событий, расследования инцидентов и подтверждения фактов выполнения операций в системе. Экспорт логов. В Системе должна быть предусмотрена возможность выгрузки данных журналов в объеме, необходимом для анализа, контроля, подготовки отчетности, проведения проверок и расследования инцидентов. Экспорт логов должен обеспечивать возможность отбора данных по периоду, пользователю, типу события, объекту системы и иным параметрам, необходимым для последующей обработки и анализа. Форматы выгрузки, состав экспортируемых данных и порядок предоставления доступа к логам определяются функциональными возможностями системы, требованиями Заказчика и установленными правилами безопасности Значение характеристики не может изменяться участником закупки Требования к уведомлениям и маршрутизации задач Типы уведомлений. В Системе должна быть предусмотрена возможность формирования и направления уведомлений пользователям в рамках выполнения функциональных процессов, задач, поручений, согласований, контроля сроков и иных событий системы. Уведомления могут использоваться для информирования пользователей о создании, изменении, назначении, согласовании, возврате, завершении, отклонении или наступлении контрольных сроков по объектам и процессам системы. В системе должны поддерживаться уведомления, формируемые по событиям, по изменению статусов, по контрольным срокам, по действиям пользователей и по иным основаниям, предусмотренным функциональными сценариями работы модулей. Эскалации и контроль сроков. Система должна обеспечивать контроль сроков исполнения задач, поручений, согласований, процессуальных действий и иных операций, для которых в системе устанавливаются плановые, контрольные или предельные сроки. При наступлении заданных условий система должна обеспечивать формирование уведомлений, напоминаний и эскалаций, направляемых исполнителям, ответственным лицам, руководителям или иным участникам процесса в соответствии с установленными правилами. Механизмы контроля сроков и эскалации должны обеспечивать повышение исполнительской дисциплины, своевременное выявление рисков нарушения сроков и поддержку принятия управленческих решений Значение характеристики не может изменяться участником закупки Требования к уведомлениям и маршрутизации задач 2 Настройка маршрутов согласования. В Системе должна быть предусмотрена возможность настройки маршрутов согласования документов, задач, поручений, заявок, приказов и иных объектов, для которых в рамках функциональных процессов требуется последовательное или параллельное прохождение согласующих этапов. Маршруты согласования должны учитывать тип объекта, категорию процесса, роль пользователя, принадлежность к подразделению, уровень ответственности и иные параметры, необходимые для корректной организации согласования. Система должна обеспечивать возможность изменения и адаптации маршрутов согласования в соответствии с требованиями Заказчика, а также фиксацию этапов согласования, принятых решений, комментариев, сроков и статусов прохождения маршрута Значение характеристики не может изменяться участником закупки Требования к отчетности и выгрузке данных Регламентные отчеты по модулям В Системе должна быть предусмотрена возможность формирования регламентных отчетов по функциональным модулям в соответствии с задачами подразделений Заказчика и установленными требованиями к представлению информации. Состав, структура и содержание отчетов должны определяться функциональным назначением соответствующего модуля и обеспечивать получение сведений о состоянии процессов, объектах учета, сроках, статусах, результатах исполнения, показателях деятельности и иных данных, необходимых пользователям. Регламентные отчеты должны формироваться на основании данных, содержащихся в системе, с учетом прав доступа пользователей и установленного порядка использования отчетной информации. Дашборды руководства В Системе должна быть предусмотрена возможность отображения управленческой информации в форме дашбордов, предназначенных для оперативного анализа состояния процессов, исполнительской дисциплины, сроков, показателей деятельности или иных сведений, необходимых руководству Заказчика. Дашборды должны обеспечивать наглядное представление сводной информации по ключевым направлениям деятельности, а также возможность перехода к более детализированным данным в пределах доступных пользователю полномочий. Состав отображаемых показателей, структура дашбордов и перечень доступных аналитических представлений определяются требованиями Заказчика и функциональными возможностями внедряемой системы Значение характеристики не может изменяться участником закупки Требования к отчетности и выгрузке данных 2 Экспорт данных В Системе должна быть предусмотрена возможность выгрузки данных, отчетов, справочников, карточек, журналов и иных информационных объектов в объеме, необходимом для последующей обработки, анализа, хранения, представления и использования в деятельности Заказчика. Экспорт данных должен обеспечиваться в распространенных электронных форматах, используемых в работе Заказчика, с учетом структуры выгружаемой информации, прав доступа пользователей и особенностей соответствующего функционального модуля. Порядок, состав и ограничения выгрузки данных определяются настройками системы, ролью пользователя и установленными правилами работы с информацией. API для отчетности При необходимости в Системе должна быть предусмотрена возможность предоставления данных для отчетности и аналитики посредством программных интерфейсов взаимодействия. Использование API может предусматриваться для передачи данных во внешние аналитические средства, смежные информационные системы, витрины данных и иные решения, используемые Заказчиком для формирования, консолидации и визуализации отчетной информации. Состав предоставляемых данных, формат взаимодействия, правила доступа и порядок использования API определяются проектными решениями, требованиями Заказчика и настройками интеграционного взаимодействия Значение характеристики не может изменяться участником закупки Требования к надежности Доступность, отказоустойчивость, восстановление работоспособности Система должна обеспечивать уровень надежности, достаточный для выполнения предусмотренных функциональных процессов, хранения и обработки данных, работы пользователей, формирования отчетности и взаимодействия с внешними и смежными информационными системами. При эксплуатации системы должны быть предусмотрены меры, направленные на обеспечение доступности функциональных модулей, сохранности данных, устойчивости работы основных компонентов и возможности восстановления работоспособности системы после сбоев, отказов или иных нештатных ситуаций. Требования к устойчивости интеграций и очередям обмена Механизмы интеграционного взаимодействия Системы с внешними и смежными информационными системами должны обеспечивать устойчивость обмена данными, контролируемую обработку сообщений и снижение риска потери информации при возникновении ошибок передачи, временной недоступности отдельных систем или иных нештатных ситуаций. При реализации интеграционных сценариев должны быть предусмотрены механизмы регистрации операций обмена, обработки ошибок, повторной передачи данных, контроля состояния обмена и, при необходимости, использования очередей сообщений либо иных средств буферизации и гарантированной доставки данных. Интеграционные механизмы должны обеспечивать возможность восстановления обмена после сбоев, сохранения целостности передаваемой информации и контроля корректности обработки данных на стороне взаимодействующих систем Значение характеристики не может изменяться участником закупки Требования к информационной безопасности Общие требования ИБ, модель угроз В Системе должны быть реализованы организационные и технические меры по защите информации в соответствии с законодательством Российской Федерации в области информации, информационных технологий, защиты информации и персональных данных. При формировании требований к защите информации должны учитываться положения Федерального закона № 149-ФЗ, согласно которому защита информации обеспечивается правовыми, организационными и техническими мерами, а также положения Федерального закона № 152-ФЗ в части обработки персональных данных. Для системы должна быть выполнена идентификация актуальных угроз безопасности информации, определены категории обрабатываемой информации, состав защищаемых ресурсов, нарушители, возможные сценарии реализации угроз и последствия нарушений конфиденциальности, целостности и доступности информации. На основании этого должна формироваться модель угроз и, при необходимости, иные организационно-распорядительные документы по защите информации. Для ИСПДн состав и содержание мер защиты должны определяться с учетом уровня защищенности персональных данных по Постановлению Правительства РФ № 1119 и приказу ФСТЭК России № 21. Если внедряемая Система либо ее отдельные подсистемы относятся к государственным информационным системам, иным информационным системам государственных органов, государственных унитарных предприятий или государственных учреждений, должны применяться новые требования ФСТЭК России, утвержденные приказом № 117 от 11.04.2025, вступившие в силу с 1 марта 2026 года. Эти требования заменили прежний режим по приказу ФСТЭК России № 17 для соответствующей категории систем Значение характеристики не может изменяться участником закупки Требования к информационной безопасности 2 При использовании шифровальных (криптографических) средств в составе системы либо при защите каналов связи и хранимой информации должны учитываться требования ФСБ России. Для ИСПДн с использованием СКЗИ действует приказ ФСБ России № 378 от 10.07.2014, а для государственных и иных систем государственных органов, ГУПов и госучреждений — приказ ФСБ России № 117 от 18.03.2025, вступивший в силу 6 апреля 2025 года. Регистрация событий безопасности В Системе должна быть обеспечена регистрация событий безопасности, достаточная для выявления попыток несанкционированного доступа, анализа инцидентов, контроля действий пользователей и администраторов, а также подтверждения фактов выполнения значимых операций в системе. Журналы безопасности должны формироваться по ключевым событиям аутентификации, изменению прав доступа, обращению к защищаемым данным, действиям администраторов, сбоям средств защиты, событиям интеграционного взаимодействия и иным событиям, значимым для безопасности. Записи журналов должны быть защищены от несанкционированного изменения и удаления, храниться в течение сроков, установленных внутренними регламентами Заказчика и проектными решениями, и быть доступны ограниченному кругу уполномоченных лиц. Для систем, подпадающих под регулирование ФСТЭК России, регистрация событий безопасности и контроль действий пользователей являются составной частью обязательных мер защиты информации; для ИСПДн и государственных систем это вытекает из приказов ФСТЭК № 21 и № 117. При использовании СКЗИ и иных специализированных средств защиты должна быть обеспечена регистрация событий, связанных с их эксплуатацией, отказами, изменением параметров и применением ключевой информации — в объеме, предусмотренном нормативными требованиями и эксплуатационной документацией. При необходимости должна быть предусмотрена возможность централизованного сбора и анализа журналов безопасности Значение характеристики не может изменяться участником закупки Требования к защите от несанкционированного доступа Идентификация и аутентификация В Системе должны быть реализованы механизмы идентификации и аутентификации пользователей, обеспечивающие допуск к системе только лиц, которым предоставлены соответствующие полномочия. Механизмы доступа должны обеспечивать однозначное сопоставление действий в системе с конкретной учетной записью пользователя, а также исключать возможность несанкционированного доступа к данным и функциям системы. При организации доступа должны учитываться корпоративные механизмы идентификации и аутентификации, используемые в ИТ-инфраструктуре Заказчика, включая подходы к централизованному управлению учетными записями. Для пользователей, администраторов и иных категорий лиц должны быть определены правила регистрации, предоставления, изменения, блокировки и прекращения доступа. Для ИСПДн и иных систем, подпадающих под регулирование ФСТЭК России, меры по идентификации и аутентификации должны определяться в составе организационных и технических мер защиты с учетом категории системы, модели угроз и уровня защищенности. Политики паролей, сеансов, многофакторной аутентификации В Системе должны быть предусмотрены политики управления аутентификационными данными и пользовательскими сеансами, обеспечивающие ограничение риска несанкционированного доступа. Такие политики должны охватывать требования к созданию, замене и хранению паролей, правила блокировки доступа при многократных ошибках ввода, управление длительностью пользовательских сеансов, завершение неактивных сеансов и иные параметры, необходимые для безопасной эксплуатации системы. Указанные меры должны устанавливаться в рамках общих требований к защите информации и предотвращению неправомерного доступа Значение характеристики не может изменяться участником закупки Требования к защите от несанкционированного доступа 2 При необходимости, с учетом категории пользователей, критичности функций, характера обрабатываемой информации и принятой модели угроз, в системе должна быть предусмотрена возможность применения многофакторной аутентификации. Решение о применении MFA, категориях пользователей, для которых она обязательна, и порядке ее использования должно приниматься на этапе проектирования системы и настройки мер защиты информации. Для привилегированных учетных записей и пользователей с доступом к чувствительным данным усиленные меры аутентификации рекомендуется предусматривать в обязательном порядке как часть комплекса организационных и технических мер защиты. Управление доступом к данным и функциям Система должна обеспечивать управление доступом к данным, документам, объектам учета, отчетности, административным функциям и иным возможностям системы на основе ролевой модели и принципа минимально необходимого объема полномочий. Пользователю должен предоставляться только тот доступ, который необходим для выполнения его служебных обязанностей и участия в предусмотренных бизнес-процессах. Защита информации по Федеральному закону № 149-ФЗ включает предотвращение неправомерного доступа, модифицирования, блокирования, копирования и иных неправомерных действий в отношении информации, что должно учитываться при проектировании механизмов авторизации. Управление доступом должно учитывать роль пользователя, принадлежность к подразделению, участие в конкретном процессе, статус исполнителя, согласующего, администратора или иного участника, а также иные атрибуты, необходимые для ограничения доступа к функциям и данным системы. Должны быть предусмотрены механизмы предоставления, изменения, временного делегирования, отзыва и прекращения прав доступа, а также фиксация таких действий в журнале безопасности. Для систем, в которых обрабатываются персональные данные или иная информация ограниченного доступа, состав мер по управлению доступом должен определяться с учетом применимых требований НПА Значение характеристики не может изменяться участником закупки Требования к обработке персональных данных Реестр ПДн В Системе должно быть предусмотрено ведение реестра персональных данных, обрабатываемых в рамках автоматизируемых процессов. Реестр должен обеспечивать фиксацию категорий субъектов персональных данных, состава обрабатываемых персональных данных, целей обработки, правовых оснований обработки, сроков хранения, действий с персональными данными, а также сведений о подразделениях и пользователях, имеющих доступ к соответствующим данным. Реестр ПДн должен использоваться как средство учета и контроля состава обрабатываемых сведений, а также как основа для последующей настройки прав доступа, аудита операций, определения необходимости получения согласий, применения мер защиты и реализации процедур блокирования, удаления либо обезличивания данных. Согласия субъектов и их версионность В Системе должна быть предусмотрена возможность регистрации, хранения и учета согласий субъектов персональных данных в случаях, когда обработка персональных данных осуществляется на основании согласия. В системе должна быть обеспечена возможность ведения версий согласий, фиксации даты их предоставления, срока действия, способа получения, статуса действия, а также хранения связанной подтверждающей информации. Версионность необходима для подтверждения правомерности обработки на конкретный момент времени и для отслеживания изменений условий согласия, включая изменение перечня данных, целей обработки и способов использования персональных данных. Отзыв согласий и обработка последствий В Системе должна быть предусмотрена возможность регистрации факта отзыва согласия субъектом персональных данных, даты и основания такого отзыва, а также запуска дальнейших действий по обработке его последствий. Значение характеристики не может изменяться участником закупки Требования к обработке персональных данных 2 После регистрации отзыва система должна обеспечивать возможность определения дальнейшего режима обработки данных: продолжение обработки при наличии законных оснований, ограничение отдельных операций, блокирование, удаление, уничтожение либо обезличивание персональных данных — в зависимости от правового основания, категории данных и требований внутренних регламентов Заказчика. Если применяется обезличивание, оно должно выполняться в соответствии с требованиями законодательства. Доступ к ПДн, аудит операций, выгрузки, обезличивание В Системе должен быть реализован ограниченный доступ к персональным данным в соответствии с ролями пользователей, их полномочиями, принадлежностью к подразделениям и участием в конкретных процессах. Доступ к просмотру, изменению, выгрузке, передаче, удалению и иным операциям с ПДн должен предоставляться только в объеме, необходимом для выполнения служебных обязанностей, с обязательной фиксацией действий в журнале аудита. В системе должна быть предусмотрена регистрация операций с персональными данными, включая просмотр, изменение, выгрузку, передачу, блокирование, обезличивание и удаление данных, с указанием пользователя, даты, времени, объекта операции и характера выполненного действия. Выгрузка ПДн должна осуществляться в контролируемом порядке и только при наличии соответствующих полномочий. При необходимости обезличивания должны применяться установленные законодательством подходы и такие методы, которые исключают сохранение доступа к информации ограниченного доступа в результатах обезличивания Значение характеристики не может изменяться участником закупки Общие функциональные требования ко всем разделам Справочники и карточки сущностей Во всех функциональных разделах модуля управления деятельностью учреждения Системы должна быть предусмотрена возможность ведения справочников и карточек сущностей, соответствующих предметной области конкретного раздела. Справочники должны обеспечивать хранение, просмотр, поиск, фильтрацию, сортировку и актуализацию записей, а карточки сущностей — хранение, отображение и изменение структурированных сведений об объектах учета, документах, задачах, событиях, операциях и иных сущностях, предусмотренных функциональностью раздела. Состав реквизитов справочников и карточек, правила их заполнения и порядок отображения определяются функциональным назначением соответствующего разделах модуля управления деятельностью учреждения и требованиями Заказчика. Статусы и жизненные циклы Для сущностей, используемых в функциональных разделах модуля управления деятельностью учреждения Системы, должны быть предусмотрены статусы и/или жизненные циклы, отражающие этапы их создания, обработки, согласования, исполнения, завершения, архивного хранения либо иного состояния. Изменение статусов должно осуществляться в соответствии с установленными правилами, маршрутами согласования, пользовательскими полномочиями или логикой соответствующего процесса. Система должна обеспечивать фиксацию текущего статуса сущности, историю его изменения, а также возможность использования статусов в механизмах поиска, фильтрации, контроля сроков, отчетности и интеграционного обмена Значение характеристики не может изменяться участником закупки Общие функциональные требования ко всем разделам 2 Вложения, версии документов Во всех разделах модуля управления деятельностью учреждения, где это требуется по функциональному назначению, должна быть предусмотрена возможность прикрепления вложений и работы с документами, связанными с объектами учета, задачами, поручениями, карточками, реестрами или иными сущностями. Система должна обеспечивать хранение вложенных файлов, их привязку к соответствующим сущностям, а также, при необходимости, ведение версий документов и истории изменений. Для документов и вложений должны быть предусмотрены механизмы контроля актуальности, доступа, замены, загрузки новых редакций и хранения связанной информации о пользователях, выполнивших соответствующие действия. Контроль сроков, уведомления, эскалации Во всех функциональных разделах модуля управления деятельностью учреждения Системы, где предусмотрены процессы с контрольными, плановыми, регламентными или предельными сроками, должна быть реализована возможность контроля таких сроков. Система должна обеспечивать автоматическое отслеживание наступления контрольных событий, формирование уведомлений пользователям, напоминаний о приближении сроков, а также эскалаций при риске нарушения либо факте нарушения установленных сроков в соответствии с принятыми регламентами Заказчика. Правила уведомлений, напоминаний и эскалаций определяются логикой соответствующего раздела модуля управления деятельностью учреждения , установленными маршрутами процессов и требованиями Заказчика Значение характеристики не может изменяться участником закупки Общие функциональные требования ко всем разделам 3 Отчетность и экспорт Во всех функциональных разделах модуля управления деятельностью учреждения Системы, которые предполагают за собой наличие «полезной» информации для Заказчика, должна быть предусмотрена возможность формирования отчетности по данным, объектам учета, статусам, срокам, результатам исполнения, действиям пользователей или иным сведениям, необходимым для решения задач соответствующего подразделения. Система должна обеспечивать формирование отчетных представлений, выгрузку справочников, карточек, журналов, аналитических выборок и иных данных в объеме, предусмотренном функциональностью конкретного раздела. Состав отчетности, форматы экспорта и объем доступных пользователю данных определяются назначением раздела модуля управления деятельностью учреждения, правами доступа и требованиями Заказчика. Аудит и история изменений Во всех функциональных разделах модуля управления деятельностью учреждения Системы должна быть предусмотрена фиксация действий пользователей и истории изменений по ключевым сущностям, объектам учета, документам, статусам, маршрутам, срокам и иным данным, изменение которых имеет значение для контроля и прослеживаемости процессов. Система должна обеспечивать хранение сведений о создании, изменении, удалении, согласовании, исполнении, передаче, назначении и иных действиях, совершаемых пользователями в рамках работы с данными и объектами системы. Состав фиксируемых событий, глубина хранения истории и доступ к журналам аудита определяются функциональным назначением раздела, требованиями информационной безопасности и правилами администрирования системы Значение характеристики не может изменяться участником закупки Раздел «Интеграция со смежными системами» Интеграция с АЗД Раздел должен обеспечивать двустороннюю интеграцию с системой автоматизации закупочной деятельности (АЗД) для обмена данными по закупкам, контрактам, этапам исполнения и финансовым резервам. Данная функциональность необходима для синхронизации финансовых и закупочных данных, контроля исполнения обязательств и предотвращения несоответствия данных между системами. Функциональность должна включать: получение данных по заявкам и закупкам из АЗД; получение данных по контрактам и этапам исполнения; получение данных о финансовых резервах и обязательствах; синхронизацию статусов закупок и финансовых резервов; протоколирование операций обмена; контроль ошибок при обмене; возможность повторной обработки данных при сбоях. Интеграция с СЭД «Практика» Раздел должен обеспечивать интеграционное взаимодействие с системой электронного документооборота «Практика» в части получения, передачи и актуализации данных, связанных с документами, резолюциями, поручениями, исполнителями и сроками исполнения. Данная функциональность необходима для синхронизации управленческих процессов между системой и действующим контуром электронного документооборота. Функциональность должна включать: получение документов из СЭД «Практика»; передачу документов в СЭД «Практика»; получение резолюций из СЭД «Практика»; передачу резолюций и связанных данных; синхронизацию карточек документов; синхронизацию карточек поручений; синхронизацию исполнителей; синхронизацию сроков исполнения; получение актуальных статусов документов; получение актуальных статусов поручений; отображение статуса документа на основе данных СЭД «Практика»; отображение статуса поручения на основе данных СЭД «Практика»; передачу результатов исполнения обратно в СЭД «Практика»; передачу подтверждающих материалов; фиксацию результатов обмена данными; контроль корректности интеграционного взаимодействия Значение характеристики не может изменяться участником закупки Раздел «Работа ПИДК» Статусы работы ИДК Раздел «Работа ПИДК» должен обеспечивать ведение и отображение статусов работы ПИДК в рамках единого информационного контура. Данная функциональность предназначена для оперативного контроля текущего состояния ПИДК, фиксации изменений в работе и предоставления пользователям актуальной информации о статусе объектов и связанных с ними процессов. Система должна обеспечивать возможность присвоения, изменения и отображения статусов работы ПИДК, а также использования этих статусов в механизмах поиска, фильтрации, контроля задач и формирования отчетности. Функциональность должна включать: ведение справочника статусов работы ПИДК; присвоение статуса объекту ПИДК; изменение текущего статуса ПИДК; отображение текущего статуса в карточке ПИДК; фиксацию истории изменения статусов; использование статусов при поиске и фильтрации; использование статусов в отчетности; контроль переходов между статусами; фиксацию даты и времени смены статуса; фиксацию пользователя, выполнившего изменение статуса. Задачи обслуживания ИДК Раздел должен обеспечивать постановку, сопровождение и контроль задач, связанных с обслуживанием ПИДК. Данная функциональность предназначена для организации работ по эксплуатации, техническому сопровождению и поддержанию ПИДК в работоспособном состоянии, а также для контроля сроков и результатов выполнения таких задач Значение характеристики не может изменяться участником закупки Раздел «Работа ПИДК» 2 Система должна обеспечивать регистрацию задач обслуживания, назначение исполнителей, фиксацию сроков, статусов и результатов выполнения, а также хранение связанной информации и подтверждающих материалов. Функциональность должна включать: создание задач обслуживания ПИДК; указание типа задачи; указание объекта ПИДК, к которому относится задача; описание содержания задачи; назначение исполнителя; назначение ответственного лица; указание планового срока выполнения; указание приоритета задачи; изменение статуса задачи; контроль сроков исполнения; формирование уведомлений по задачам; формирование напоминаний о приближении срока; формирование эскалаций при просрочке; фиксацию результатов выполнения задачи; прикрепление документов, комментариев и иных материалов; хранение истории выполнения задачи; отображение текущего состояния задач обслуживания. Отчетность по работе ИДК Раздел должен обеспечивать формирование отчетности по состоянию ПИДК, статусам работы, задачам обслуживания и результатам их выполнения. Данная функциональность предназначена для получения пользователями и руководством сводной информации о текущем состоянии объектов ПИДК, качестве и своевременности обслуживания, а также для последующего анализа и контроля. Система должна обеспечивать формирование отчетных и аналитических представлений на основании данных раздела с возможностью отбора информации по заданным параметрам. Функциональность должна включать: формирование отчетности по статусам работы ПИДК; формирование отчетности по задачам обслуживания; формирование отчетности по срокам исполнения задач; формирование отчетности по просроченным задачам; формирование отчетности по исполнителям; формирование отчетности по объектам ПИДК; формирование аналитических выборок за заданный период; использование фильтров при формировании отчетности; выгрузку отчетов в установленных форматах; представление отчетной информации в виде, удобном для последующего анализа Значение характеристики не может изменяться участником закупки Раздел «Потребности ГКО» Список потребностей ГКО Раздел «Потребности ГКО» должен обеспечивать ведение перечня потребностей ГКО в рамках единого информационного пространства. Данная функциональность предназначена для централизованного учета заявленных потребностей, упорядочивания работы с ними и предоставления пользователям актуальной информации о текущем состоянии исполнения. Система должна обеспечивать формирование и ведение списка потребностей с возможностью просмотра, поиска, фильтрации и использования сведений о потребностях в контрольных, исполнительских и отчетных сценариях. Функциональность должна включать: ведение списка потребностей ГКО; создание карточки потребности; отображение основных реквизитов потребности; указание инициатора потребности; указание ответственного лица; указание подразделения; указание описания потребности; указание даты создания; указание текущего статуса; поиск потребностей по основным реквизитам; фильтрацию потребностей по статусам; фильтрацию потребностей по ответственным лицам; фильтрацию потребностей по срокам; отображение истории изменений по потребности; использование списка потребностей при формировании отчетности. Создание потребности Раздел должен обеспечивать регистрацию новых потребностей ГКО и их последующее включение в общий контур учета и исполнения. Данная функциональность предназначена для формализации процесса инициирования потребности, фиксации ее параметров и обеспечения возможности дальнейшего контроля выполнения Значение характеристики не может изменяться участником закупки Раздел «Потребности ГКО» 2 Создание потребности должно осуществляться с заполнением обязательных реквизитов и последующей передачей потребности в работу в соответствии с установленной логикой разделя. Функциональность должна включать: создание новой потребности; заполнение карточки потребности; указание наименования потребности; указание описания потребности; указание инициатора; указание ответственного исполнителя; указание подразделения; указание приоритета; указание срока исполнения; прикрепление связанных документов и материалов; сохранение потребности в системе; присвоение начальному статусу; возможность редактирования потребности до передачи в исполнение; фиксацию даты и времени создания; фиксацию пользователя, создавшего потребность. Выполнение потребности Раздел должен обеспечивать сопровождение процесса выполнения потребности ГКО с фиксацией всех значимых действий, этапов и результатов исполнения. Данная функциональность предназначена для контроля исполнения заявленных потребностей и обеспечения прослеживаемости работы по каждой из них. Система должна обеспечивать назначение исполнителей, изменение статусов, фиксацию результатов выполнения и хранение подтверждающих материалов по завершении работ. Функциональность должна включать: передачу потребности в исполнение; назначение исполнителя; назначение соисполнителей при необходимости; изменение статусов в процессе выполнения; фиксацию этапов исполнения; добавление комментариев по ходу выполнения; прикрепление подтверждающих документов и материалов; фиксацию результата выполнения; завершение исполнения потребности; указание причины возврата или невозможности исполнения при необходимости; хранение истории действий по выполнению потребности; отображение текущего состояния исполнения в карточке потребности Значение характеристики не может изменяться участником закупки Раздел «Потребности ГКО» 3 Контроль статусов и сроков потребностей Раздел должен обеспечивать контроль статусов и сроков исполнения потребностей ГКО. Данная функциональность предназначена для своевременного выявления рисков просрочки, контроля текущего состояния потребностей и информирования ответственных лиц о необходимости выполнения действий. Система должна обеспечивать использование статусов и сроков как инструментов управления исполнением, контроля дисциплины и подготовки отчетной информации. Функциональность должна включать: контроль текущего статуса потребности; контроль сроков исполнения потребности; фиксацию плановой даты исполнения; фиксацию фактической даты исполнения; формирование уведомлений о приближении срока; формирование напоминаний ответственным лицам; формирование эскалаций при риске просрочки; формирование эскалаций при факте просрочки; использование статусов и сроков в поиске и фильтрации; использование статусов и сроков в отчетности; отображение просроченных потребностей; отображение потребностей, требующих внимания пользователя Значение характеристики не может изменяться участником закупки Раздел «База знаний» Список документов и инструкций Раздел «База знаний» должен обеспечивать централизованное ведение перечня документов, инструкций и иных информационных материалов, используемых в деятельности Заказчика. Данная функциональность предназначена для предоставления пользователям единой точки доступа к актуальным нормативным, методическим и справочным материалам, необходимым для выполнения служебных обязанностей. Система должна обеспечивать формирование структурированного списка документов и инструкций с возможностью поиска, просмотра, фильтрации и последующего использования материалов в рамках рабочих процессов. Функциональность должна включать: ведение списка документов и инструкций; создание карточки документа или инструкции; указание наименования документа; указание категории или типа документа; указание даты размещения; указание статуса актуальности; указание ответственного за материал; привязку документа к тематике, подразделению или направлению деятельности; поиск документов по наименованию и основным реквизитам; фильтрацию документов по категориям, статусам и иным признакам; просмотр карточки документа; переход к содержимому документа или вложенному файлу Значение характеристики не может изменяться участником закупки Раздел «База знаний» 2 Хранение и актуализация материалов Раздел должен обеспечивать хранение материалов базы знаний, их актуализацию и сопровождение в процессе эксплуатации системы. Данная функциональность предназначена для поддержания базы знаний в актуальном состоянии, контроля версий материалов и обеспечения пользователей достоверной информацией. Система должна обеспечивать хранение файлов, текстовых материалов и связанных данных, а также фиксацию изменений, выполняемых в отношении документов и инструкций. Функциональность должна включать: загрузку документов и инструкций в систему; хранение файлов и материалов; обновление ранее размещенных материалов; замену неактуальных версий документов; хранение истории изменений; ведение версий материалов; фиксацию даты актуализации; фиксацию пользователя, внесшего изменение; изменение статуса актуальности материала; архивирование устаревших материалов; контроль доступности пользователям только актуальных материалов в пределах заданной логики; прикрепление сопроводительных файлов и комментариев при необходимости. Опросы Раздел должен обеспечивать создание, проведение и сопровождение опросов пользователей по тематике, связанной с документами, инструкциями, внутренними регламентами и иными материалами базы знаний. Данная функциональность предназначена для сбора обратной связи, проверки ознакомления с материалами и получения сведений, необходимых для внутреннего контроля и анализа. Система должна обеспечивать подготовку опросов, определение состава участников, фиксацию ответов и хранение результатов прохождения. Функциональность должна включать: создание опросов; указание наименования опроса; формирование перечня вопросов; настройку вариантов ответов; определение целевой аудитории опроса; назначение сроков прохождения; публикацию опроса для пользователей; сбор ответов пользователей; фиксацию даты и времени прохождения; хранение результатов опроса; повторное проведение опроса при необходимости; использование результатов опросов в отчетности Значение характеристики не может изменяться участником закупки Раздел «База знаний» 3 Тестирование Раздел должен обеспечивать проведение тестирования пользователей по материалам базы знаний, внутренним инструкциям, регламентам и иным документам, размещенным в системе. Данная функциональность предназначена для проверки уровня ознакомления пользователей с материалами, контроля усвоения информации и подтверждения прохождения обязательных процедур. Система должна обеспечивать формирование тестов, назначение их пользователям или группам пользователей, фиксацию результатов прохождения и хранение истории тестирования. Функциональность должна включать: создание тестов; формирование набора вопросов для тестирования; настройку правильных ответов; определение правил прохождения теста; назначение тестирования пользователям; назначение тестирования группам пользователей; указание срока прохождения теста; фиксацию факта начала тестирования; фиксацию факта завершения тестирования; расчет результата прохождения; отображение результата пользователю; хранение истории прохождения тестов; повторное назначение тестирования при необходимости Значение характеристики не может изменяться участником закупки Раздел «База знаний» 4 Отчетность по прохождению опросов и тестирования Раздел должен обеспечивать формирование отчетности по прохождению опросов и тестирования пользователями. Данная функциональность предназначена для контроля исполнительской дисциплины, анализа результатов и предоставления руководству и ответственным лицам сведений о степени прохождения материалов и проверочных мероприятий. Система должна обеспечивать формирование отчетных и аналитических представлений на основании накопленных данных по опросам и тестам с возможностью отбора информации по пользователям, подразделениям, срокам и результатам. Функциональность должна включать: формирование отчетности по прохождению опросов; формирование отчетности по прохождению тестирования; отображение списка пользователей, прошедших опрос; отображение списка пользователей, не прошедших опрос; отображение списка пользователей, прошедших тестирование; отображение списка пользователей, не прошедших тестирование; формирование отчетности по срокам прохождения; формирование отчетности по результатам тестирования; формирование аналитики по подразделениям; формирование аналитики по группам пользователей; использование фильтров при подготовке отчетов; выгрузку отчетных данных в установленных форматах Значение характеристики не может изменяться участником закупки Раздел «Дашборд и навигация между модулями» Стартовая страница Раздел дашборда должен обеспечивать пользователю единый интерфейс для доступа к основным функциональным модулям системы и сводной информации. Данная функциональность предназначена для упрощения навигации, повышения оперативности доступа к ключевым данным и контроля состояния процессов в разных модулях. Функциональность должна включать: отображение сводной информации по состоянию ключевых показателей (KPI) и задач; визуализацию состояния процессов по модулям; доступ к отдельным функциональным блокам модулей по нажатию на соответствующие элементы интерфейса; возможность расширения и группировки блоков в раздел «В разработке» для модулей, находящихся в стадии внедрения; адаптивное отображение для разных устройств (ПК, планшет, мобильный телефон); предоставление краткой аналитической информации по каждому модулю на стартовой странице; поддержку интерактивного перехода к модулям с сохранением единой авторизации Значение характеристики не может изменяться участником закупки Раздел «Дашборд и навигация между модулями» 2 Модульные блоки Модульные блоки дашборда должны представлять собой визуальные элементы, отражающие доступные функциональные модули и их текущее состояние. Данная функциональность предназначена для быстрого выбора и перехода к интересующим модулям, а также для обеспечения наглядного контроля над рабочими процессами. Функциональность должна включать: отображение блоков по каждому модулю; выделение модулей, находящихся в стадии внедрения, с указанием статуса «В разработке»; возможность перехода к модулю из блока дашборда; группировку блоков по категориям или состоянию разработки; отображение уведомлений о критических событиях или сроках в рамках модуля; настройку порядка и размера блоков на странице; поддержку интерактивного расширения групп модулей; единый стиль отображения для всех модулей с сохранением единых UI-паттернов Значение характеристики не может изменяться участником закупки Раздел «Пресс?служба» Сбор и парсинг новостей Раздел пресс-службы должен обеспечивать автоматизированный мониторинг информационного поля по заданным источникам с последующим сбором и обработкой новостных публикаций. Функциональность данного подпункта предназначена для сокращения доли ручной работы сотрудников пресс-службы, повышения полноты мониторинга и обеспечения оперативного выявления значимых информационных сообщений. Система должна обеспечивать получение новостных публикаций из определенного перечня источников, извлечение значимых атрибутов публикации и сохранение результатов мониторинга для дальнейшей классификации, анализа и работы сотрудников пресс-службы. Функциональность должна включать: автоматический сбор новостей из заранее определенного перечня источников; получение данных с сайтов СМИ, официальных сайтов ведомств, официальных каналов, RSS-лент и иных источников, определенных Заказчиком; обработку новостных публикаций по заданной периодичности; парсинг заголовка публикации; парсинг текста публикации; парсинг даты и времени публикации; парсинг сведений об авторе публикации при наличии; парсинг сведений об источнике публикации; сохранение ссылки на первоисточник; исключение либо отметку дублирующихся публикаций при повторном обнаружении; сохранение результатов сбора в системе для последующего анализа и обработки Значение характеристики не может изменяться участником закупки Раздел «Пресс?служба» 2 Настройка источников мониторинга Раздел должен обеспечивать настройку и сопровождение источников, используемых для автоматического мониторинга новостей. Указанная функциональность необходима для гибкого управления перечнем отслеживаемых ресурсов и параметрами получения информации в зависимости от задач пресс-службы. Настройка источников мониторинга должна обеспечивать возможность изменения состава отслеживаемых ресурсов, определения периодичности опроса и задания параметров, влияющих на поиск, отбор и дальнейшую обработку публикаций. Функциональность должна включать: добавление новых источников мониторинга; изменение параметров ранее добавленных источников; отключение и повторное включение источников мониторинга; указание URL или иного идентификатора источника; настройку периодичности опроса источника; привязку источника к категориям мониторинга; указание ключевых слов и поисковых условий; настройку принадлежности источника к тематике, региону, организации или иному классификационному признаку; ведение перечня активных и неактивных источников; хранение параметров настройки по каждому источнику Значение характеристики не может изменяться участником закупки Раздел «Пресс?служба» 3 Классификация новостей Раздел должен обеспечивать классификацию новостных публикаций по признакам, необходимым для анализа информационного поля, последующей фильтрации данных и формирования отчетности. Классификация должна использоваться как для автоматизированной обработки публикаций, так и для поддержки аналитической работы сотрудников пресс-службы. Результаты классификации должны сохраняться в системе и использоваться при поиске, фильтрации, группировке публикаций и подготовке аналитических материалов. Функциональность должна включать: классификацию публикаций по темам; классификацию публикаций по регионам; классификацию публикаций по организациям; классификацию публикаций по уровню значимости; возможность автоматического присвоения классификационных признаков по заданным правилам; возможность ручной корректировки классификации пользователем; использование классификационных признаков в поиске, фильтрации, отчетности и аналитике; сохранение результатов классификации в карточке публикации Значение характеристики не может изменяться участником закупки Раздел «Пресс?служба» 4 Ручная загрузка новостей Раздел должен обеспечивать возможность ручного внесения новостных публикаций в систему в случаях, когда информация не была получена автоматически либо должна быть добавлена сотрудником пресс-службы отдельно. Такая функциональность необходима для обеспечения полноты учета и сохранения в системе всех значимых публикаций, подлежащих рассмотрению и анализу. Ручное добавление новостей должно осуществляться в рамках общей логики работы раздела с возможностью последующего редактирования, классификации, анализа и использования публикации в отчетности. Функциональность должна включать: создание карточки новости вручную; ввод заголовка публикации; ввод текста публикации; указание даты публикации; указание автора при наличии; указание источника публикации; добавление ссылки на первоисточник при наличии; присвоение тематических и иных классификационных признаков; прикрепление файлов и сопроводительных материалов при необходимости; сохранение вручную добавленных новостей в общем контуре мониторинга; возможность последующего редактирования вручную добавленной информации в рамках установленных прав доступа Значение характеристики не может изменяться участником закупки Раздел «Пресс?служба» 5 История мониторинга и действия пресс?службы по публикациям Раздел должен обеспечивать накопление и хранение истории работы с публикациями, начиная с момента их обнаружения или загрузки в систему и заканчивая обработкой сотрудниками пресс-службы. Указанная функциональность необходима для обеспечения прослеживаемости действий, анализа реакции на публикации и формирования полной картины работы по каждому информационному сообщению. История публикации должна отражать изменения ее состояния, действия пользователей, результаты анализа и иные сведения, связанные с рассмотрением и сопровождением публикации в системе. Функциональность должна включать: хранение истории поступления публикации в систему; фиксацию даты и времени обнаружения публикации; сохранение истории изменений карточки публикации; ведение истории классификации и переклассификации; фиксацию действий сотрудников пресс-службы по публикации; хранение отметок о рассмотрении публикации; хранение комментариев, решений, служебных пометок и иных сведений по публикации; возможность просмотра аналитики по публикации; сохранение истории связанных действий и событий в карточке публикации; использование истории публикации для последующего анализа и отчетности Значение характеристики не может изменяться участником закупки Раздел «Пресс?служба» 6 Экспорт отчетов Раздел должен обеспечивать формирование отчетности по результатам мониторинга и возможность выгрузки подготовленных материалов в распространенные форматы. Указанная функциональность предназначена для подготовки аналитических материалов, служебной отчетности и предоставления сведений руководству и заинтересованным подразделениям. Отчетность должна формироваться на основании данных, накопленных в системе, с учетом параметров поиска, фильтрации, классификации и аналитических признаков публикаций. Функциональность должна включать: формирование отчетов по собранным публикациям; формирование отчетов по источникам мониторинга; формирование отчетов по темам, регионам, организациям и уровням значимости; формирование отчетов по действиям пресс-службы; формирование аналитических выборок за заданный период; применение фильтров при формировании отчетов; выгрузку отчетов в формат Excel; выгрузку отчетов в формат PDF; возможность экспорта данных по результатам поиска и фильтрации; сохранение сформированных отчетов в системе при необходимости Значение характеристики не может изменяться участником закупки Раздел «Безопасность и гражданская оборона» Оповещение и экстренный обзвон сотрудников Раздел безопасности и гражданской обороны должен обеспечивать оперативное оповещение сотрудников при возникновении чрезвычайных, аварийных, эвакуационных и иных значимых событий. Данная функциональность предназначена для централизованной организации экстренного информирования работников и сокращения времени доведения информации до ответственных лиц и групп реагирования через мобильное приложение «АСУР». Система должна обеспечивать выполнение сценариев массового и адресного оповещения с использованием функциональных средств «АСУР» или иных каналов информирования, предусмотренных составом внедряемой функциональности. Функциональность должна включать: запуск оповещения по заранее определенным спискам получателей; формирование и использование перечней сотрудников для оповещения; фиксацию факта направления оповещения; фиксацию статуса доставки или результата оповещения в пределах технически доступных возможностей; сохранение истории проведенных оповещений; отображение информации о текущем и завершенном оповещении. Сценарии оповещения по типам событий Раздел должен обеспечивать формирование и использование сценариев оповещения в зависимости от типа события, характера угрозы, состава вовлеченных подразделений и категорий получателей. Указанная функциональность необходима для стандартизации действий при различных ситуациях и сокращения времени подготовки оповещения. Сценарии оповещения должны задавать состав получателей, порядок использования каналов связи, текстовое или голосовое содержание сообщений, а также правила дальнейшего информирования и эскалации Значение характеристики не может изменяться участником закупки Раздел «Безопасность и гражданская оборона» 2 Функциональность должна включать: создание сценариев оповещения по типам событий; настройку сценариев для событий, связанных с пожаром; настройку сценариев для событий, связанных с эвакуацией; настройку сценариев для событий, связанных с техногенными авариями; настройку сценариев для иных типов событий, определяемых Заказчиком; привязку сценария к составу получателей; привязку сценария к приоритетам оповещения; настройку каналов оповещения в рамках сценария; хранение параметров сценариев; возможность изменения и актуализации сценариев. Запуск обзвона Раздел должен обеспечивать запуск обзвона и оповещения как по инициативе пользователя, так и по заранее установленным условиям, правилам и событиям. Такая функциональность необходима для поддержки как оперативного реагирования, так и регламентных действий, выполняемых без ручного участия оператора. Запуск обзвона должен учитывать выбранный сценарий, состав получателей, приоритетность групп, используемые каналы оповещения и иные параметры, определенные в настройках системы. Функциональность должна включать: запуск обзвона в ручном режиме; запуск обзвона в автоматическом режиме; использование заранее настроенных регламентных триггеров; выбор сценария оповещения при запуске; выбор групп или отдельных получателей; фиксацию даты и времени запуска обзвона; отображение текущего состояния процесса оповещения; сохранение результатов выполнения обзвона; возможность остановки, повторного запуска или продолжения процедуры оповещения в рамках предусмотренной логики Значение характеристики не может изменяться участником закупки Раздел «Безопасность и гражданская оборона» 3 Голосовые шаблоны сообщений Раздел должен обеспечивать использование заранее подготовленных голосовых шаблонов сообщений для автоматизированного обзвона и информирования сотрудников. Указанная функциональность необходима для стандартизации содержания сообщений, сокращения времени на подготовку оповещения и обеспечения единообразного доведения информации до получателей. Голосовые шаблоны должны использоваться в рамках сценариев оповещения и быть доступны для выбора, привязки и изменения в соответствии с полномочиями пользователей. Функциональность должна включать: создание голосовых шаблонов сообщений; хранение голосовых шаблонов в системе; выбор голосового шаблона при настройке сценария; привязку шаблона к типу события; использование шаблона при запуске обзвона; изменение и актуализацию шаблонов; хранение нескольких вариантов шаблонов для разных сценариев; использование шаблонов для массового и адресного оповещения. Каскадный обзвон по приоритетным группам Раздел должен обеспечивать каскадный обзвон сотрудников с учетом заранее определенной очередности групп и приоритетов информирования. Такая функциональность необходима для соблюдения установленного порядка оповещения, в котором сначала информируются наиболее критичные категории получателей, а затем остальные участники процесса. Каскадный обзвон должен использоваться для организации поэтапного доведения информации до руководства, дежурных служб, ответственных лиц, сотрудников объектов и иных групп, определяемых Заказчиком. Функциональность должна включать: настройку приоритетных групп получателей; задание очередности обзвона групп; запуск обзвона по каскадной схеме; выделение групп руководства; выделение групп дежурных служб; выделение групп сотрудников объектов; переход к следующей группе в соответствии с настроенной логикой; фиксацию результатов оповещения по каждой группе; использование каскадного обзвона в рамках сценариев оповещения Значение характеристики не может изменяться участником закупки Раздел «Безопасность и гражданская оборона» 4 Альтернативные каналы Раздел должен обеспечивать использование альтернативных каналов информирования в случаях, когда основной способ оповещения недоступен, недостаточен либо требует дублирования сообщения. Указанная функциональность предназначена для повышения надежности системы оповещения и обеспечения доставки информации до получателей в различных условиях. Альтернативные каналы могут использоваться как резервный или дополнительный способ уведомления в составе единого сценария оповещения. Функциональность должна включать: использование резервных каналов информирования; использование нескольких каналов в рамках одного сценария; отправку сообщений по альтернативному каналу при недоступности основного; отправку уведомлений по SMS; отправку уведомлений по электронной почте; отправку push-уведомлений; фиксацию факта использования альтернативного канала; сохранение результатов доставки или попытки доставки в пределах технически доступных возможностей; настройку логики переключения между каналами оповещения Значение характеристики не может изменяться участником закупки Раздел «Управление информационных технологий» Раздел персональных данных и согласий Раздел Управления информационных технологий в части персональных данных должен обеспечивать централизованный учет сведений о субъектах персональных данных, основаниях их обработки, согласиях на обработку и передачу данных, а также связанных с этим действиях пользователей и системы. Данная функциональность предназначена для упорядочивания работы с персональными данными, обеспечения прослеживаемости операций и снижения рисков неконтролируемой обработки сведений. Раздел должен использоваться для ведения структурированных данных о составе обрабатываемых персональных данных, статусах согласий, сроках хранения, действиях с данными и основаниях обработки, а также для последующего контроля, аудита и исполнения процедур, связанных с отзывом согласия. Функциональность должна включать: ведение справочника субъектов персональных данных; ведение сведений о категориях субъектов персональных данных; ведение сведений о составе хранимых персональных данных; учет категорий персональных данных; учет правовых оснований обработки персональных данных; учет сроков хранения персональных данных; регистрацию согласий на обработку персональных данных; регистрацию согласий на передачу персональных данных; хранение согласий в системе; ведение версий согласий; отображение текущего статуса согласия; фиксацию статуса «действует»; фиксацию статуса «отозвано»; фиксацию статуса «истекло»; контроль операций с персональными данными; учет операций просмотра; учет операций изменения; учет операций выгрузки; учет операций удаления; учет операций обезличивания; ведение журнала аудита по персональным данным; фиксацию сведений о пользователе, выполнившем операцию; фиксацию даты и времени операции; фиксацию состава обработанных данных; фиксацию основания обработки Значение характеристики не может изменяться участником закупки Раздел «Управление информационных технологий» 2 Учет учетных записей и телефонный справочник Раздел должен обеспечивать ведение сведений об учетных записях пользователей и сопровождение корпоративного телефонного справочника. Данная функциональность предназначена для централизованного учета учетных записей, их статусов, связи с сотрудниками и подразделениями, а также для предоставления актуальной справочной информации, используемой в повседневной работе пользователей и в функциональных сценариях других разделах. Система должна обеспечивать ведение структурированных сведений об учетных записях, их жизненном цикле, принадлежности к сотрудникам и организационной структуре, а также поддержку поиска и использования контактных данных в справочном и прикладном режимах. Функциональность должна включать: ведение справочника учетных записей; регистрацию учетных записей; изменение учетных записей; блокировку учетных записей; архивирование учетных записей; привязку учетной записи к сотруднику; привязку учетной записи к подразделению; привязку учетной записи к роли; привязку учетной записи к полномочиям; фиксацию статуса учетной записи; отображение статуса «активна»; отображение статуса «временно заблокирована»; отображение статуса «деактивирована»; ведение корпоративного телефонного справочника; хранение ФИО; хранение должности; хранение подразделения; хранение контактных данных; поиск по сотруднику; поиск по подразделению; поиск по должности; поиск по номеру телефона; актуализацию сведений справочника; использование справочных данных в иных модулях Системы Значение характеристики не может изменяться участником закупки Раздел «Управление информационных технологий» 3 Автоматические действия при отзыве согласия Раздел должен обеспечивать автоматизированную обработку событий, связанных с отзывом согласия субъекта персональных данных, в пределах логики, допустимой действующими правилами обработки данных и внутренними регламентами Заказчика. Данная функциональность предназначена для сокращения ручных операций, повышения управляемости процессов прекращения обработки и обеспечения фиксации результатов выполненных действий. После регистрации отзыва согласия система должна обеспечивать запуск предусмотренных процедур в отношении соответствующих персональных данных, включая ограничение дальнейшей обработки, формирование задач, фиксацию статусов и выполнение последующих операций в зависимости от настроенной логики и оснований обработки. Функциональность должна включать: регистрацию события отзыва согласия; запуск процедуры обработки последствий отзыва; проверку наличия оснований для дальнейшей обработки данных; ограничение дальнейших операций с персональными данными при отсутствии оснований; запуск процедуры прекращения обработки персональных данных; инициирование удаления персональных данных в допустимых случаях; инициирование обезличивания персональных данных в допустимых случаях; формирование задач ответственным пользователям при необходимости ручной обработки; фиксацию даты запуска процедуры; фиксацию основания выполнения действий; фиксацию перечня обработанных данных; фиксацию результата выполнения процедуры; хранение подтверждения исполнения отзыва; отображение статуса исполнения действий по отзыву согласия; сохранение истории всех связанных операций в журнале аудита Значение характеристики не может изменяться участником закупки Раздел «Административное управление» Учет материальных ценностей Раздел административного управления должен обеспечивать централизованный учет материальных ценностей в рамках единого информационного пространства. Данная функциональность предназначена для систематизации сведений о материальных ценностях, контролю их состояния, местонахождения, ответственных лиц и истории движения. Система должна обеспечивать ведение карточек материальных ценностей, учет количественных и стоимостных характеристик, фиксацию статусов и сопровождение операций, связанных с жизненным циклом каждой единицы учета. Функциональность должна включать: ведение единого справочника материальных ценностей; формирование карточки материальной ценности; присвоение инвентарных номеров; присвоение учетных номеров; классификацию материальных ценностей по типам; учет количественных показателей; учет стоимостных показателей; учет состояния материальной ценности; учет местонахождения материальной ценности; учет закрепления за сотрудниками; учет закрепления за подразделениями; фиксацию ответственных лиц; хранение истории операций по каждой единице учета; формирование первичных учетных форм; формирование отчетов по движению материальных ценностей Значение характеристики не может изменяться участником закупки Раздел «Административное управление» 2 Выдача и передача материальных ценностей Раздел должен обеспечивать сопровождение процессов выдачи, возврата и передачи материальных ценностей между сотрудниками, подразделениями и материально ответственными лицами. Данная функциональность предназначена для контроля движения материальных ценностей, подтверждения оснований передачи и фиксации текущего держателя каждой единицы учета. Система должна обеспечивать оформление операций передачи, хранение сопроводительных документов и контроль сроков временной выдачи с возможностью формирования уведомлений и последующего анализа движения материальных ценностей. Функциональность должна включать: оформление заявок на выдачу материальных ценностей; поддержку маршрутов согласования заявок; регистрацию операций выдачи; регистрацию операций возврата; регистрацию операций передачи между подразделениями; регистрацию операций передачи между материально ответственными лицами; контроль оснований выдачи; контроль оснований передачи; учет заявки как основания выдачи; учет приказа как основания выдачи; учет акта как основания передачи; формирование актов приема-передачи; хранение актов приема-передачи; хранение сопроводительных документов; контроль сроков временной выдачи; формирование уведомлений о сроках возврата; отслеживание текущего держателя материальной ценности; отслеживание текущего статуса материальной ценности Значение характеристики не может изменяться участником закупки Раздел «Административное управление» 3 Инвентаризация Раздел должен обеспечивать планирование, проведение и фиксацию результатов инвентаризации материальных ценностей. Данная функциональность предназначена для проверки фактического наличия материальных ценностей, выявления расхождений с учетными данными и документирования итогов инвентаризационных мероприятий. Система должна обеспечивать формирование инвентаризационных ведомостей, учет результатов проверки, фиксацию излишков, недостач и иных расхождений, а также подготовку итоговых документов и аналитической отчетности. Функциональность должна включать: планирование плановых инвентаризаций; планирование внеплановых инвентаризаций; проведение инвентаризаций по подразделениям; проведение инвентаризаций по локациям; проведение инвентаризаций по материально ответственным лицам; формирование инвентаризационных ведомостей; фиксацию фактического наличия материальных ценностей; фиксацию состояния материальных ценностей; фиксацию расхождений с учетными данными; оформление результатов инвентаризации; учет излишков; учет недостач; учет пересортицы; оформление списания; оформление доначисления; поддержку фотофиксации; прикрепление подтверждающих документов; формирование итоговых актов; формирование аналитической отчетности по результатам инвентаризации Значение характеристики не может изменяться участником закупки Раздел «Управление закупок» Централизованная консолидация данных Раздел управления закупок должен обеспечивать централизованное получение, сведение и консолидацию финансовых данных из всех модулей и разделов Системы и смежных информационных систем. Данная функциональность предназначена для формирования единого контура закупочного учета, сопоставимости показателей между управлениями и прозрачности финансовых потоков. Функциональность должна включать: сбор финансовых данных из модулей и разделов; сведение данных в единую структуру для сопоставимости; консолидацию плановых данных; консолидацию фактических данных; анализ данных по управлению, объекту, статье, периоду и источнику финансирования; формирование сводного финансового баланса по организации. Учет бюджетных обязательств и лимитов Раздел должен обеспечивать ведение лимитов бюджетных обязательств (ЛБО) и контроль их использования в рамках финансового планирования. Данная функциональность предназначена для предотвращения превышения бюджетных лимитов, контроля кассового плана и соблюдения бюджетной дисциплины Значение характеристики не может изменяться участником закупки Раздел «Управление закупок» 2 Функциональность должна включать: ведение лимитов бюджетных обязательств по периодам и направлениям; резервирование лимитов при инициации закупки; корректировку лимитов по факту исполнения; автоматическую проверку доступности лимитов при создании финансовых операций; блокировку или перевод на согласование операций при превышении лимита; контроль кассового плана в режиме план/факт. Планирование и план?графики Раздел должен обеспечивать формирование и ведение финансовых планов и план-графиков закупок, а также контроль изменений и отклонений. Данная функциональность предназначена для соблюдения бюджетной дисциплины и согласованного распределения ресурсов. Функциональность должна включать: формирование финансовых планов; формирование план-графиков закупок; учет изменений план-графиков с сохранением истории версий; сверку план-графика с бюджетными параметрами; контроль отклонений от плана; фиксацию причин изменений; хранение истории изменений планов Значение характеристики не может изменяться участником закупки Раздел «Управление закупок» 3 Контроль и согласование Раздел должен обеспечивать контроль соблюдения правил бюджетной дисциплины, согласование финансовых операций и корректировок бюджета. Данная функциональность необходима для снижения рисков превышения лимитов, несоответствия статьям бюджета и нарушения сроков исполнения. Функциональность должна включать: настройку маршрутов согласования финансовых документов; настройку маршрутов согласования корректировок бюджета; контроль соблюдения бюджетной дисциплины; применение контрольных правил; уведомления ответственных лиц при критических отклонениях; уведомления при риске кассового разрыва; уведомления при нарушении сроков исполнения. Аналитика и отчетность Раздел должен обеспечивать контроль соблюдения правил бюджетной дисциплины, согласование финансовых операций и корректировок бюджета. Данная функциональность необходима для снижения рисков превышения лимитов, несоответствия статьям бюджета и нарушения сроков исполнения. Функциональность должна включать: настройку маршрутов согласования финансовых документов; настройку маршрутов согласования корректировок бюджета; контроль соблюдения бюджетной дисциплины; применение контрольных правил (превышение лимита, несоответствие статьям, дублирование обязательств); уведомления ответственных лиц при критических отклонениях; уведомления при риске кассового разрыва; уведомления при нарушении сроков исполнения Значение характеристики не может изменяться участником закупки Раздел «Управление комплектации и ремонта» Контроль исполнения задач Раздел управления комплектации и ремонта должен обеспечивать регистрацию, сопровождение и контроль выполнения задач, связанных с работами по обеспечению объектов оборудованием, комплектующими и проведением ремонтных мероприятий. Данная функциональность предназначена для повышения прозрачности процессов, контроля сроков и качества выполнения задач. Функциональность должна включать: создание и ведение задач (тип задачи, объект/локация, описание, приоритет, сроки, ответственные); назначение исполнителей и возможность переназначения с фиксацией причины; формирование исполнительской отчетности по задаче (фотофиксация, прикрепление документов, комментарии); контроль сроков исполнения: план/факт, просрочка, критичность отклонений; автоматические уведомления о ключевых сроках, возвратах и просрочках; эскалация руководителю при нарушении сроков; ведение журнала действий и истории изменений по задаче (аудит); формирование дашбордов и отчетов по дисциплине исполнения, просрочкам, нагрузке по подразделениям и исполнителям; интеграция с АЗД для привязки задач к заявкам/закупкам и получения/передачи статусов. Проверка заявок Раздел должен обеспечивать автоматическую проверку заявок на комплектацию и ремонт. Данная функциональность предназначена для повышения точности проверки, сокращения ошибок и ускорения обработки заявок Значение характеристики не может изменяться участником закупки Раздел «Управление комплектации и ремонта» 2 Функциональность должна включать: автоматическую проверку полноты комплекта документов (обоснование, КП, ТЗ, расчет НМЦК, план-график); проверку обоснования закупки; сопоставление данных ТЗ и КП (наименование закупки, характеристики, единицы измерения, объемы); контроль срока актуальности КП (не старше установленного периода); проверку реквизитов КП (подпись, дата, ответственное лицо); проверку контрагентов (существование, корректность данных, соответствие по ОКВЭД, проверка по РНП); выявление признаков аффилированности по заданным правилам; проверку бюджетно-классификационных параметров (ЦСР, ВР, КОСГУ, ОКПД-2, сумма, наименование); проверку корректности расчета НМЦК (логические/арифметические несоответствия); сверку заявки с планом-графиком по ключевым реквизитам; формирование результата проверки: список замечаний, уровень критичности, рекомендации по исправлению, решение (допустить/вернуть). Проверка смет Раздел должен обеспечивать автоматизированную проверку сметной документации. Данная функциональность предназначена для выявления типовых ошибок, проверки полноты и корректности структуры смет, а также формирования аналитической информации о качестве смет. Функциональность должна включать: загрузку сметной документации; проверку структуры сметы и полноты обязательных разделов; выявление типовых ошибок и несоответствий; классификацию замечаний по критичности: критичные, существенные, рекомендательные; формирование протокола проверки (ошибка, обоснование, ссылка на раздел/позицию, рекомендация к исправлению); поддержку процесса проверки филиал ? центральный аппарат с возвратом на доработку и повторной проверкой; хранение истории версий смет; хранение истории замечаний и исправлений; формирование аналитической отчетности по качеству смет и повторяемости ошибок Значение характеристики не может изменяться участником закупки Раздел «Реестр событий информационной безопасности» Реестр событий информационной безопасности Раздел должен обеспечивать ведение единого реестра событий информационной безопасности, связанных с потенциальными и фактическими утечками информации. Данная функциональность предназначена для централизованного учета инцидентов, их анализа и обеспечения прозрачности процессов реагирования. Функциональность должна включать: создание и ведение карточек событий ИБ; указание типа инцидента (утечка, попытка утечки, нарушение политики доступа и др.); указание источника события (пользователь, система, внешнее подключение); фиксацию времени и даты события; указание затронутых информационных ресурсов; классификацию уровня критичности инцидента; назначение ответственных за обработку инцидента; хранение истории изменений и статусов инцидента; возможность фильтрации и поиска событий по ключевым параметрам. Паспорт инцидента информационной безопасности Раздел должен обеспечивать формирование и хранение паспорта инцидента информационной безопасности в структурированном виде. Данная функциональность позволяет централизованно хранить всю информацию по инциденту и контролировать полноту и актуальность данных. Функциональность должна включать: структурированное хранение данных по инциденту; фиксацию описания инцидента; хранение доказательной базы (логи, файлы, скриншоты); хранение результатов расследования; фиксацию принятых мер реагирования; хранение сопутствующих документов; ведение версий паспорта инцидента; контроль актуальности информации; возможность интеграции с системами сбора логов Значение характеристики не может изменяться участником закупки Результаты внедрения модуля По результатам внедрения модуля Заказчик должен получить единый информационный контур для автоматизации и сопровождения деятельности структурных подразделений, обеспечивающий централизованный доступ к данным, документам, задачам, отчетности и иным объектам учета в рамках установленных полномочий пользователей. Результатами внедрения системы являются: автоматизация ключевых процессов структурных подразделений Заказчика в рамках предусмотренных функциональных модулей; создание единой точки входа пользователей в систему с разграничением прав доступа по ролям и полномочиям; сокращение доли ручных операций при обработке документов, поручений, заявок, справочников, карточек объектов и иных сущностей; повышение прозрачности бизнес-процессов, статусов исполнения, сроков и результатов деятельности подразделений; обеспечение контроля исполнительской дисциплины, сроков исполнения задач, поручений, согласований и процессуальных действий; обеспечение централизованного хранения данных, документов, вложений, версий и истории изменений; повышение достоверности, актуальности и полноты информации, используемой в работе подразделений; обеспечение возможности оперативного поиска, фильтрации, анализа и выгрузки данных; формирование регламентной, аналитической и управленческой отчетности по направлениям деятельности; обеспечение интеграционного взаимодействия с внешними и смежными информационными системами в пределах предусмотренного объема работ; создание условий для дальнейшего развития системы, подключения новых модулей, сервисов и пользовательских сценариев; повышение качества управленческих решений за счет консолидации информации и доступа к актуальным данным в единой системе Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Цели внедрения модуля - Целями внедрения модуля управления деятельностью учреждения являются повышение эффективности управления внутренними процессами Заказчика, формирование единого цифрового пространства для взаимодействия структурных подразделений, обеспечение централизованного учета данных, а также сокращение сроков обработки информации, документов, поручений и управленческих решений. Внедрение модуля должна обеспечить унификацию и формализацию бизнес-процессов, повышение прозрачности исполнения задач и поручений, снижение зависимости от разрозненных информационных ресурсов и ручных операций, а также повышение качества контроля сроков, статусов и результатов деятельности подразделений. Дополнительными целями внедрения являются: обеспечение единой точки входа пользователей в модули системы; создание сквозного контура работы с данными, документами, задачами, отчетностью и интеграциями; автоматизация функциональных процессов подразделений Заказчика; повышение достоверности, полноты и актуальности данных; обеспечение оперативного получения аналитической и управленческой отчетности; обеспечение возможности масштабирования системы за счет подключения новых модулей, сервисов и интеграций; создание технологической основы для дальнейшего развития цифровых сервисов Заказчика - - Значение характеристики не может изменяться участником закупки - Раздел «Реестр событий информационной безопасности» 2 - Контур реагирования на инциденты Раздел должен обеспечивать управление процессом реагирования на инциденты информационной безопасности. Данная функциональность предназначена для минимизации последствий утечек и обеспечения соблюдения регламентов реагирования. Функциональность должна включать: назначение ответственных за обработку инцидентов; управление статусами инцидентов (новый, в работе, закрыт и др.); контроль сроков реагирования; фиксацию действий по устранению инцидента; автоматическое уведомление участников процесса; контроль исполнения регламентов реагирования; эскалацию критических инцидентов; формирование отчетов по реагированию; поддержку маршрутов согласования решений. Мониторинг и отчетность Раздел должен обеспечивать мониторинг состояния информационной безопасности, уровня рисков утечки информации и ключевых показателей эффективности. Данная функциональность предназначена для предоставления актуальной информации руководству и ответственным подразделениям. Функциональность должна включать: формирование дашбордов по инцидентам ИБ; мониторинг уровня угроз и рисков утечки; контроль количества и динамики инцидентов; анализ эффективности мер защиты; выявление критических отклонений; контроль времени реагирования на инциденты; формирование регламентированной отчетности; выгрузку отчетов в Excel и PDF; формирование аналитических срезов по типам инцидентов, подразделениям, пользователям и периодам - - Значение характеристики не может изменяться участником закупки - Результаты внедрения модуля 2 - Дополнительно результатом внедрения системы должно стать формирование единого подхода к работе пользователей с цифровыми сервисами Заказчика, включая единые правила доступа, маршрутизации, уведомлений, журналирования действий, формирования документов и использования общих справочников. В результате внедрения системы должны быть обеспечены условия для последующей промышленной эксплуатации, сопровождения, развития функциональности и масштабирования системы в соответствии с потребностями Заказчика - - Значение характеристики не может изменяться участником закупки - Общие требования к системе - Назначение, режимы функционирования Система предназначена для автоматизации внутренних процессов Заказчика, информационной поддержки деятельности структурных подразделений, централизованного ведения данных, документов, задач, поручений, справочников и карточек учета, а также для формирования отчетности и обеспечения межмодульного взаимодействия. Система должна функционировать в режиме многопользовательской работы с обеспечением одновременного доступа пользователей к предусмотренным функциональным возможностям в пределах их полномочий. Единая точка входа и единая авторизация. Доступ пользователей к Системе должен быть организован по принципу единой точки входа с последующим предоставлением доступа к доступным функциональным модулям в соответствии с ролями и полномочиями пользователя. При внедрении системы должны быть предусмотрены единые механизмы идентификации и аутентификации пользователей, обеспечивающие централизованный доступ к системе без необходимости использования отдельных механизмов входа для каждого модуля. Организация доступа к системе должна учитывать корпоративную модель управления учетными записями пользователей, используемую в ИТ-инфраструктуре Заказчика, включая подходы к идентификации и авторизации. Модульность и масштабирование. Система должна строиться по модульному принципу, предусматривающему возможность независимого подключения, настройки, развития и сопровождения отдельных функциональных модулей в рамках единого системного контура. Архитектура системы должна обеспечивать возможность поэтапного расширения состава модулей, функций, пользовательских сценариев, отчетных форм, интеграций и сервисов без необходимости переработки уже внедренных компонентов. Система должна обеспечивать возможность масштабирования по количеству пользователей, составу автоматизируемых подразделений, объему обрабатываемых данных, количеству подключаемых модулей и числу интеграционных взаимодействий - - Значение характеристики не может изменяться участником закупки - Требования к структуре модулей системы - Общая архитектура. Архитектура системы должна обеспечивать функционирование единой цифровой среды, объединяющей функциональные модули, общие сервисы, механизмы хранения и обработки данных, средства управления доступом, инструменты журналирования, уведомления, отчетности и интеграционного взаимодействия. Архитектурные решения должны обеспечивать целостность системы, согласованность работы функциональных модулей, возможность централизованного администрирования, а также условия для последующего развития, адаптации и расширения функциональности без нарушения общей логики работы системы. Развитие функционала должно предусматривать единые подходы к организации пользовательского доступа, обработке данных, использованию общих справочников, хранению документов и истории изменений, а также к взаимодействию между модулями и внешними системами. Состав модулей и связи между ними. Структура системы должна предусматривать наличие функциональных модулей, автоматизирующих отдельные направления деятельности Заказчика, при сохранении их работы в рамках единого информационного контура. Состав модулей определяется требованиями настоящего Технического задания и может включать модули, предназначенные для автоматизации процессов пресс-службы, безопасности и гражданской обороны, учета персональных данных и согласий, административного управления, управления комплектацией и ремонта, а также иные модули, предусмотренные проектными решениями и этапами внедрения. Связи между модулями должны обеспечивать возможность обмена данными, использования единых справочников, передачи статусов, задач, документов, уведомлений и иных сущностей, необходимых для сквозного выполнения процессов и формирования консолидированной отчетности - - Значение характеристики не может изменяться участником закупки - Контур развертывания - Развертывание системы должно осуществляться на контуре Заказчика. Состав используемых сред, порядок развертывания, размещения компонентов системы, хранения данных, настройки серверной части, доступа пользователей и эксплуатации системы определяются с учетом ИТ-инфраструктуры Заказчика, требований информационной безопасности, эксплуатационных ограничений и проектных решений, принимаемых в рамках внедрения. При развертывании системы на контуре Заказчика должны быть обеспечены условия для функционирования пользовательской, серверной, интеграционной и сервисной составляющих системы. Общие сервисы. В структуре системы должны использоваться общие сервисы, обеспечивающие единые механизмы работы функциональных модулей и пользователей в рамках всей системы. К общим сервисам относятся, в частности, сервисы аутентификации и авторизации, ведения справочников, поиска, журналирования действий, хранения вложений и документов, формирования уведомлений, маршрутизации процессов, формирования отчетности, а также сервисы интеграционного взаимодействия. Использование общих сервисов должно обеспечивать единообразие пользовательских сценариев, повторное использование функциональных механизмов, снижение дублирования решений между модулями и упрощение сопровождения и развития Системы - - Значение характеристики не может изменяться участником закупки - Перечень разделов - В состав модуля управления деятельностью учреждения должны входить разделы, обеспечивающие автоматизацию основных направлений деятельности Заказчика в рамках единого информационного пространства. Перечень разделов модуля управления деятельностью учреждения определяется настоящим Техническим заданием и включает: раздел «Работа ПИДК»; раздел «Потребности ГКО»; раздел «База знаний»; раздел «Дашборд и средства навигации между модулями»; раздел «Пресс-служба»; раздел «Безопасность и гражданская оборона»; раздел «Управление информационных технологий»; раздел «Административное управление»; раздел «Управление закупок»; раздел «Управление комплектации и ремонта»; раздел «Реестр событий информационной безопасности»; раздел «Интеграция со смежными системами»; иные разделы, предусмотренные этапами внедрения, проектными решениями и потребностями Заказчика. Требования к подключению новых разделов. Функциональные разделы модуля управления деятельностью учреждения должны внедряться как составные части единой системы с обеспечением единых подходов к пользовательскому доступу, обработке данных, ведению справочников, журналированию действий, хранению документов, формированию отчетности и интеграционному взаимодействию. Каждый функциональный раздел должен обеспечивать выполнение предусмотренных для него задач, поддержку соответствующих пользовательских сценариев, возможность работы в рамках установленной ролевой модели и взаимодействие с иными разделами и модулями Системы в части передачи и получения данных, статусов, документов, уведомлений и иных сущностей - - Значение характеристики не может изменяться участником закупки - Ролевая модель - В Системе должна быть реализована ролевая модель доступа, обеспечивающая предоставление пользователям прав в зависимости от их функциональных обязанностей, участия в бизнес-процессах, принадлежности к структурным подразделениям и уровня ответственности. Ролевая модель должна обеспечивать возможность назначения пользователям одной или нескольких ролей, определяющих состав доступных функций, данных, документов, отчетности и действий в системе. Состав ролей, их полномочия и правила назначения должны определяться в рамках настройки системы с учетом требований Заказчика, организационной структуры и особенностей автоматизируемых процессов. Разграничение доступа. Система должна обеспечивать разграничение доступа к функциональным возможностям, данным, документам, карточкам учета, задачам, отчетности и иным объектам системы в соответствии с назначенными ролями и полномочиями пользователей. Разграничение доступа должно учитывать не только роль пользователя, но и его принадлежность к подразделению, участие в конкретном процессе, статус исполнителя, согласующего или администратора, а также иные параметры, необходимые для ограничения доступа к информации и действиям в системе. Доступ к данным и функциям системы должен предоставляться по принципу достаточности полномочий, необходимому для выполнения пользователем его служебных задач - - Значение характеристики не может изменяться участником закупки - Делегирование, замещение, соисполнители - В Системе должна быть предусмотрена возможность делегирования отдельных полномочий, временного замещения пользователей, а также назначения соисполнителей в рамках задач, поручений, согласований и иных процессов, где требуется участие нескольких пользователей. Механизмы делегирования и замещения должны обеспечивать передачу прав и обязанностей на установленный период времени либо в пределах определенного процесса с учетом ограничений, заданных ролевой моделью и правилами доступа. При назначении соисполнителей система должна обеспечивать возможность распределения задач между несколькими участниками процесса, фиксации их роли в исполнении, контроля сроков и учета действий каждого участника. Администрирование ролей и журналирование изменений прав. Система должна обеспечивать возможность централизованного администрирования ролей, полномочий и параметров доступа пользователей. Должна быть предусмотрена возможность назначения, изменения, временного предоставления, ограничения и прекращения прав доступа пользователей в соответствии с установленными правилами администрирования. Изменения в составе ролей, правах пользователей, делегированных полномочиях и настройках доступа должны фиксироваться в журнале системы с указанием сведений о выполненном действии, пользователе, инициировавшем изменение, дате и времени выполнения операции - - Значение характеристики не может изменяться участником закупки - Требования к интерфейсу пользователя - Стартовая страница. В Системе должна быть предусмотрена стартовая страница, обеспечивающая пользователю удобный доступ к основным функциональным модулям, разделам, сервисам, уведомлениям и элементам навигации. Стартовая страница должна использоваться как единая точка входа в систему после прохождения авторизации и обеспечивать отображение доступных пользователю разделов в зависимости от его роли, полномочий и настроек доступа. На стартовой странице может предусматриваться размещение информационных блоков, виджетов, индикаторов, уведомлений, ссылок на модули, разделы, а также иных элементов, необходимых для организации быстрого перехода к основным пользовательским сценариям. Навигация. Интерфейс Системы должен обеспечивать понятную и единообразную навигацию между функциональными модулями, разделами, карточками, справочников, задачами, документами и иными объектами системы. Навигационные элементы должны обеспечивать пользователю быстрый переход к доступным разделам системы, возможность возврата к предыдущим экранам, переход на стартовую страницу, а также доступ к основным операциям в рамках текущего сценария работы. Навигация должна учитывать состав доступных пользователю модулей и функций, а также обеспечивать удобство работы при большом количестве функциональных разделов системы - - Значение характеристики не может изменяться участником закупки - Требования к интерфейсу пользователя 2 - Адаптивность интерфейса. Интерфейс Системы должен обеспечивать корректное отображение и использование основных функциональных возможностей при работе с различных типов пользовательских устройств, включая персональные компьютеры, планшеты и мобильные устройства, в объеме, предусмотренном проектными решениями и требованиями Заказчика. Адаптивность интерфейса должна обеспечивать сохранение логики пользовательских сценариев, доступности основных элементов управления и читаемости отображаемой информации при изменении разрешения экрана, размеров рабочей области и типа используемого устройства. Единые UI?паттерны. Интерфейс Системы должен строиться с использованием единых UI-паттернов, обеспечивающих единообразное отображение элементов управления, карточек, справочников, форм ввода, уведомлений, фильтров, статусов, маршрутов согласования, отчетных блоков и иных компонентов пользовательского интерфейса. Использование единых UI-паттернов должно обеспечивать предсказуемость пользовательских действий, снижение времени на освоение системы, единый визуальный подход к работе в различных функциональных модулях, а также упрощение дальнейшего развития и сопровождения интерфейса Системы - - Значение характеристики не может изменяться участником закупки - Требования к ведению справочников и классификаторов - Единые корпоративные справочники. В Системе должно быть предусмотрено ведение единых корпоративных справочников и классификаторов, используемых функциональными модулями системы для обеспечения единообразия данных, унификации подходов к учету и исключения дублирования сведений. К единым корпоративным справочникам могут относиться справочники организационной структуры, подразделений, должностей, сотрудников, ролей, типов документов, статусов, категорий объектов учета, контрагентов, видов операций и иные справочники, необходимые для функционирования системы. Использование единых корпоративных справочников должно обеспечивать согласованность данных между модулями и разделами Системы, поддержку сквозных процессов, корректность фильтрации, поиска, отчетности и интеграционного обмена. Версионность справочников и контроль изменений. Система должна обеспечивать возможность фиксации изменений, вносимых в справочники и классификаторы, с сохранением истории таких изменений в объеме, необходимом для обеспечения прослеживаемости и контроля актуальности данных. При необходимости должна быть предусмотрена возможность ведения версий отдельных справочников, контроля даты вступления изменений в силу, а также фиксации сведений о пользователе, внесшем изменение, дате и времени изменения. Изменения, вносимые в справочники и классификаторы, должны осуществляться в контролируемом порядке с учетом установленных полномочий пользователей и правил администрирования - - Значение характеристики не может изменяться участником закупки - Требования к ведению справочников и классификаторов 2 - Импорт и экспорт справочников. В Системе должна быть предусмотрена возможность импорта и экспорта справочников и классификаторов в объеме, необходимом для первичного заполнения, актуализации данных, переноса сведений и обеспечения интеграционного взаимодействия. Импорт и экспорт справочников должны обеспечивать загрузку и выгрузку данных в распространенных электронных форматах, используемых в деятельности Заказчика, с учетом требований к структуре данных, полноте реквизитов и контролю корректности загружаемой информации. Порядок импорта, экспорта, обновления и синхронизации справочников определяется проектными решениями, настройками системы и правилами ведения нормативно-справочной информации - - Значение характеристики не может изменяться участником закупки - Требования к поиску, фильтрации и сортировке данных - Полнотекстовый поиск. В Системе должна быть предусмотрена возможность полнотекстового поиска по данным, документам, карточкам, справочников и иным объектам, в отношении которых такая функциональность необходима для реализации пользовательских сценариев. Полнотекстовый поиск должен обеспечивать возможность поиска по наименованиям, реквизитам, текстовому содержанию документов, комментариям, описаниям и иным доступным пользователю данным в пределах его полномочий. Результаты поиска должны отображаться в удобной для пользователя форме с возможностью последующего перехода к найденным объектам, уточнения поискового запроса и применения дополнительных условий отбора. Контекстные фильтры по реквизитам. В Системе должна быть предусмотрена возможность применения контекстных фильтров по реквизитам объектов, документов, карточек, записей справочников, задач, поручений и иных сущностей системы. Фильтрация должна обеспечивать отбор данных по значениям атрибутов, статусам, датам, подразделениям, ответственным лицам, типам объектов, категориям, срокам и иным реквизитам, используемым в соответствующем функциональном модуле. Состав доступных фильтров должен определяться особенностями конкретного раздела системы, характером отображаемых данных и правами пользователя. Сохраненные представления. В Системе должна быть предусмотрена возможность сохранения пользовательских представлений данных, включая наборы фильтров, параметры сортировки, состав и порядок отображаемых колонок, а также иные настройки экранных форм и справочников, если это предусмотрено функциональностью соответствующего модуля. Сохраненные представления должны обеспечивать удобство повторного доступа пользователя к часто используемым вариантам отображения данных и повышать эффективность работы со справочниками, списками, журналами и отчетными представлениями. Порядок создания, изменения, использования и удаления сохраненных представлений определяется функциональными возможностями системы, настройками доступа пользователя - - Значение характеристики не может изменяться участником закупки - Требования к журналированию действий пользователей - Аудит?лог по ключевым сущностям. В Системе должно быть предусмотрено журналирование действий пользователей и системных событий по ключевым сущностям, используемым в функциональных модулях системы. К таким сущностям могут относиться документы, карточки объектов учета, поручения, задачи, записи реестров, справочники, учетные записи, согласования, статусы, маршруты, вложения, отчеты и иные объекты, изменение которых требует фиксации в целях контроля, прослеживаемости и последующего анализа. Аудит-лог должен обеспечивать фиксацию сведений о выполненном действии, объекте, пользователе, дате и времени операции, а также иных параметров, необходимых для понимания характера выполненного изменения. Неизменяемость и защищенность журнала. Журнал действий пользователей должен храниться в системе с обеспечением его целостности, защищенности и недопустимости несанкционированного изменения или удаления записей. Доступ к просмотру, выгрузке и администрированию журналов должен предоставляться ограниченному кругу пользователей в соответствии с установленными ролями и полномочиями. Механизмы хранения и защиты журналов должны обеспечивать возможность использования содержащихся в них сведений для внутреннего контроля, анализа событий, расследования инцидентов и подтверждения фактов выполнения операций в системе. Экспорт логов. В Системе должна быть предусмотрена возможность выгрузки данных журналов в объеме, необходимом для анализа, контроля, подготовки отчетности, проведения проверок и расследования инцидентов. Экспорт логов должен обеспечивать возможность отбора данных по периоду, пользователю, типу события, объекту системы и иным параметрам, необходимым для последующей обработки и анализа. Форматы выгрузки, состав экспортируемых данных и порядок предоставления доступа к логам определяются функциональными возможностями системы, требованиями Заказчика и установленными правилами безопасности - - Значение характеристики не может изменяться участником закупки - Требования к уведомлениям и маршрутизации задач - Типы уведомлений. В Системе должна быть предусмотрена возможность формирования и направления уведомлений пользователям в рамках выполнения функциональных процессов, задач, поручений, согласований, контроля сроков и иных событий системы. Уведомления могут использоваться для информирования пользователей о создании, изменении, назначении, согласовании, возврате, завершении, отклонении или наступлении контрольных сроков по объектам и процессам системы. В системе должны поддерживаться уведомления, формируемые по событиям, по изменению статусов, по контрольным срокам, по действиям пользователей и по иным основаниям, предусмотренным функциональными сценариями работы модулей. Эскалации и контроль сроков. Система должна обеспечивать контроль сроков исполнения задач, поручений, согласований, процессуальных действий и иных операций, для которых в системе устанавливаются плановые, контрольные или предельные сроки. При наступлении заданных условий система должна обеспечивать формирование уведомлений, напоминаний и эскалаций, направляемых исполнителям, ответственным лицам, руководителям или иным участникам процесса в соответствии с установленными правилами. Механизмы контроля сроков и эскалации должны обеспечивать повышение исполнительской дисциплины, своевременное выявление рисков нарушения сроков и поддержку принятия управленческих решений - - Значение характеристики не может изменяться участником закупки - Требования к уведомлениям и маршрутизации задач 2 - Настройка маршрутов согласования. В Системе должна быть предусмотрена возможность настройки маршрутов согласования документов, задач, поручений, заявок, приказов и иных объектов, для которых в рамках функциональных процессов требуется последовательное или параллельное прохождение согласующих этапов. Маршруты согласования должны учитывать тип объекта, категорию процесса, роль пользователя, принадлежность к подразделению, уровень ответственности и иные параметры, необходимые для корректной организации согласования. Система должна обеспечивать возможность изменения и адаптации маршрутов согласования в соответствии с требованиями Заказчика, а также фиксацию этапов согласования, принятых решений, комментариев, сроков и статусов прохождения маршрута - - Значение характеристики не может изменяться участником закупки - Требования к отчетности и выгрузке данных - Регламентные отчеты по модулям В Системе должна быть предусмотрена возможность формирования регламентных отчетов по функциональным модулям в соответствии с задачами подразделений Заказчика и установленными требованиями к представлению информации. Состав, структура и содержание отчетов должны определяться функциональным назначением соответствующего модуля и обеспечивать получение сведений о состоянии процессов, объектах учета, сроках, статусах, результатах исполнения, показателях деятельности и иных данных, необходимых пользователям. Регламентные отчеты должны формироваться на основании данных, содержащихся в системе, с учетом прав доступа пользователей и установленного порядка использования отчетной информации. Дашборды руководства В Системе должна быть предусмотрена возможность отображения управленческой информации в форме дашбордов, предназначенных для оперативного анализа состояния процессов, исполнительской дисциплины, сроков, показателей деятельности или иных сведений, необходимых руководству Заказчика. Дашборды должны обеспечивать наглядное представление сводной информации по ключевым направлениям деятельности, а также возможность перехода к более детализированным данным в пределах доступных пользователю полномочий. Состав отображаемых показателей, структура дашбордов и перечень доступных аналитических представлений определяются требованиями Заказчика и функциональными возможностями внедряемой системы - - Значение характеристики не может изменяться участником закупки - Требования к отчетности и выгрузке данных 2 - Экспорт данных В Системе должна быть предусмотрена возможность выгрузки данных, отчетов, справочников, карточек, журналов и иных информационных объектов в объеме, необходимом для последующей обработки, анализа, хранения, представления и использования в деятельности Заказчика. Экспорт данных должен обеспечиваться в распространенных электронных форматах, используемых в работе Заказчика, с учетом структуры выгружаемой информации, прав доступа пользователей и особенностей соответствующего функционального модуля. Порядок, состав и ограничения выгрузки данных определяются настройками системы, ролью пользователя и установленными правилами работы с информацией. API для отчетности При необходимости в Системе должна быть предусмотрена возможность предоставления данных для отчетности и аналитики посредством программных интерфейсов взаимодействия. Использование API может предусматриваться для передачи данных во внешние аналитические средства, смежные информационные системы, витрины данных и иные решения, используемые Заказчиком для формирования, консолидации и визуализации отчетной информации. Состав предоставляемых данных, формат взаимодействия, правила доступа и порядок использования API определяются проектными решениями, требованиями Заказчика и настройками интеграционного взаимодействия - - Значение характеристики не может изменяться участником закупки - Требования к надежности - Доступность, отказоустойчивость, восстановление работоспособности Система должна обеспечивать уровень надежности, достаточный для выполнения предусмотренных функциональных процессов, хранения и обработки данных, работы пользователей, формирования отчетности и взаимодействия с внешними и смежными информационными системами. При эксплуатации системы должны быть предусмотрены меры, направленные на обеспечение доступности функциональных модулей, сохранности данных, устойчивости работы основных компонентов и возможности восстановления работоспособности системы после сбоев, отказов или иных нештатных ситуаций. Требования к устойчивости интеграций и очередям обмена Механизмы интеграционного взаимодействия Системы с внешними и смежными информационными системами должны обеспечивать устойчивость обмена данными, контролируемую обработку сообщений и снижение риска потери информации при возникновении ошибок передачи, временной недоступности отдельных систем или иных нештатных ситуаций. При реализации интеграционных сценариев должны быть предусмотрены механизмы регистрации операций обмена, обработки ошибок, повторной передачи данных, контроля состояния обмена и, при необходимости, использования очередей сообщений либо иных средств буферизации и гарантированной доставки данных. Интеграционные механизмы должны обеспечивать возможность восстановления обмена после сбоев, сохранения целостности передаваемой информации и контроля корректности обработки данных на стороне взаимодействующих систем - - Значение характеристики не может изменяться участником закупки - Требования к информационной безопасности - Общие требования ИБ, модель угроз В Системе должны быть реализованы организационные и технические меры по защите информации в соответствии с законодательством Российской Федерации в области информации, информационных технологий, защиты информации и персональных данных. При формировании требований к защите информации должны учитываться положения Федерального закона № 149-ФЗ, согласно которому защита информации обеспечивается правовыми, организационными и техническими мерами, а также положения Федерального закона № 152-ФЗ в части обработки персональных данных. Для системы должна быть выполнена идентификация актуальных угроз безопасности информации, определены категории обрабатываемой информации, состав защищаемых ресурсов, нарушители, возможные сценарии реализации угроз и последствия нарушений конфиденциальности, целостности и доступности информации. На основании этого должна формироваться модель угроз и, при необходимости, иные организационно-распорядительные документы по защите информации. Для ИСПДн состав и содержание мер защиты должны определяться с учетом уровня защищенности персональных данных по Постановлению Правительства РФ № 1119 и приказу ФСТЭК России № 21. Если внедряемая Система либо ее отдельные подсистемы относятся к государственным информационным системам, иным информационным системам государственных органов, государственных унитарных предприятий или государственных учреждений, должны применяться новые требования ФСТЭК России, утвержденные приказом № 117 от 11.04.2025, вступившие в силу с 1 марта 2026 года. Эти требования заменили прежний режим по приказу ФСТЭК России № 17 для соответствующей категории систем - - Значение характеристики не может изменяться участником закупки - Требования к информационной безопасности 2 - При использовании шифровальных (криптографических) средств в составе системы либо при защите каналов связи и хранимой информации должны учитываться требования ФСБ России. Для ИСПДн с использованием СКЗИ действует приказ ФСБ России № 378 от 10.07.2014, а для государственных и иных систем государственных органов, ГУПов и госучреждений — приказ ФСБ России № 117 от 18.03.2025, вступивший в силу 6 апреля 2025 года. Регистрация событий безопасности В Системе должна быть обеспечена регистрация событий безопасности, достаточная для выявления попыток несанкционированного доступа, анализа инцидентов, контроля действий пользователей и администраторов, а также подтверждения фактов выполнения значимых операций в системе. Журналы безопасности должны формироваться по ключевым событиям аутентификации, изменению прав доступа, обращению к защищаемым данным, действиям администраторов, сбоям средств защиты, событиям интеграционного взаимодействия и иным событиям, значимым для безопасности. Записи журналов должны быть защищены от несанкционированного изменения и удаления, храниться в течение сроков, установленных внутренними регламентами Заказчика и проектными решениями, и быть доступны ограниченному кругу уполномоченных лиц. Для систем, подпадающих под регулирование ФСТЭК России, регистрация событий безопасности и контроль действий пользователей являются составной частью обязательных мер защиты информации; для ИСПДн и государственных систем это вытекает из приказов ФСТЭК № 21 и № 117. При использовании СКЗИ и иных специализированных средств защиты должна быть обеспечена регистрация событий, связанных с их эксплуатацией, отказами, изменением параметров и применением ключевой информации — в объеме, предусмотренном нормативными требованиями и эксплуатационной документацией. При необходимости должна быть предусмотрена возможность централизованного сбора и анализа журналов безопасности - - Значение характеристики не может изменяться участником закупки - Требования к защите от несанкционированного доступа - Идентификация и аутентификация В Системе должны быть реализованы механизмы идентификации и аутентификации пользователей, обеспечивающие допуск к системе только лиц, которым предоставлены соответствующие полномочия. Механизмы доступа должны обеспечивать однозначное сопоставление действий в системе с конкретной учетной записью пользователя, а также исключать возможность несанкционированного доступа к данным и функциям системы. При организации доступа должны учитываться корпоративные механизмы идентификации и аутентификации, используемые в ИТ-инфраструктуре Заказчика, включая подходы к централизованному управлению учетными записями. Для пользователей, администраторов и иных категорий лиц должны быть определены правила регистрации, предоставления, изменения, блокировки и прекращения доступа. Для ИСПДн и иных систем, подпадающих под регулирование ФСТЭК России, меры по идентификации и аутентификации должны определяться в составе организационных и технических мер защиты с учетом категории системы, модели угроз и уровня защищенности. Политики паролей, сеансов, многофакторной аутентификации В Системе должны быть предусмотрены политики управления аутентификационными данными и пользовательскими сеансами, обеспечивающие ограничение риска несанкционированного доступа. Такие политики должны охватывать требования к созданию, замене и хранению паролей, правила блокировки доступа при многократных ошибках ввода, управление длительностью пользовательских сеансов, завершение неактивных сеансов и иные параметры, необходимые для безопасной эксплуатации системы. Указанные меры должны устанавливаться в рамках общих требований к защите информации и предотвращению неправомерного доступа - - Значение характеристики не может изменяться участником закупки - Требования к защите от несанкционированного доступа 2 - При необходимости, с учетом категории пользователей, критичности функций, характера обрабатываемой информации и принятой модели угроз, в системе должна быть предусмотрена возможность применения многофакторной аутентификации. Решение о применении MFA, категориях пользователей, для которых она обязательна, и порядке ее использования должно приниматься на этапе проектирования системы и настройки мер защиты информации. Для привилегированных учетных записей и пользователей с доступом к чувствительным данным усиленные меры аутентификации рекомендуется предусматривать в обязательном порядке как часть комплекса организационных и технических мер защиты. Управление доступом к данным и функциям Система должна обеспечивать управление доступом к данным, документам, объектам учета, отчетности, административным функциям и иным возможностям системы на основе ролевой модели и принципа минимально необходимого объема полномочий. Пользователю должен предоставляться только тот доступ, который необходим для выполнения его служебных обязанностей и участия в предусмотренных бизнес-процессах. Защита информации по Федеральному закону № 149-ФЗ включает предотвращение неправомерного доступа, модифицирования, блокирования, копирования и иных неправомерных действий в отношении информации, что должно учитываться при проектировании механизмов авторизации. Управление доступом должно учитывать роль пользователя, принадлежность к подразделению, участие в конкретном процессе, статус исполнителя, согласующего, администратора или иного участника, а также иные атрибуты, необходимые для ограничения доступа к функциям и данным системы. Должны быть предусмотрены механизмы предоставления, изменения, временного делегирования, отзыва и прекращения прав доступа, а также фиксация таких действий в журнале безопасности. Для систем, в которых обрабатываются персональные данные или иная информация ограниченного доступа, состав мер по управлению доступом должен определяться с учетом применимых требований НПА - - Значение характеристики не может изменяться участником закупки - Требования к обработке персональных данных - Реестр ПДн В Системе должно быть предусмотрено ведение реестра персональных данных, обрабатываемых в рамках автоматизируемых процессов. Реестр должен обеспечивать фиксацию категорий субъектов персональных данных, состава обрабатываемых персональных данных, целей обработки, правовых оснований обработки, сроков хранения, действий с персональными данными, а также сведений о подразделениях и пользователях, имеющих доступ к соответствующим данным. Реестр ПДн должен использоваться как средство учета и контроля состава обрабатываемых сведений, а также как основа для последующей настройки прав доступа, аудита операций, определения необходимости получения согласий, применения мер защиты и реализации процедур блокирования, удаления либо обезличивания данных. Согласия субъектов и их версионность В Системе должна быть предусмотрена возможность регистрации, хранения и учета согласий субъектов персональных данных в случаях, когда обработка персональных данных осуществляется на основании согласия. В системе должна быть обеспечена возможность ведения версий согласий, фиксации даты их предоставления, срока действия, способа получения, статуса действия, а также хранения связанной подтверждающей информации. Версионность необходима для подтверждения правомерности обработки на конкретный момент времени и для отслеживания изменений условий согласия, включая изменение перечня данных, целей обработки и способов использования персональных данных. Отзыв согласий и обработка последствий В Системе должна быть предусмотрена возможность регистрации факта отзыва согласия субъектом персональных данных, даты и основания такого отзыва, а также запуска дальнейших действий по обработке его последствий. - - Значение характеристики не может изменяться участником закупки - Требования к обработке персональных данных 2 - После регистрации отзыва система должна обеспечивать возможность определения дальнейшего режима обработки данных: продолжение обработки при наличии законных оснований, ограничение отдельных операций, блокирование, удаление, уничтожение либо обезличивание персональных данных — в зависимости от правового основания, категории данных и требований внутренних регламентов Заказчика. Если применяется обезличивание, оно должно выполняться в соответствии с требованиями законодательства. Доступ к ПДн, аудит операций, выгрузки, обезличивание В Системе должен быть реализован ограниченный доступ к персональным данным в соответствии с ролями пользователей, их полномочиями, принадлежностью к подразделениям и участием в конкретных процессах. Доступ к просмотру, изменению, выгрузке, передаче, удалению и иным операциям с ПДн должен предоставляться только в объеме, необходимом для выполнения служебных обязанностей, с обязательной фиксацией действий в журнале аудита. В системе должна быть предусмотрена регистрация операций с персональными данными, включая просмотр, изменение, выгрузку, передачу, блокирование, обезличивание и удаление данных, с указанием пользователя, даты, времени, объекта операции и характера выполненного действия. Выгрузка ПДн должна осуществляться в контролируемом порядке и только при наличии соответствующих полномочий. При необходимости обезличивания должны применяться установленные законодательством подходы и такие методы, которые исключают сохранение доступа к информации ограниченного доступа в результатах обезличивания - - Значение характеристики не может изменяться участником закупки - Общие функциональные требования ко всем разделам - Справочники и карточки сущностей Во всех функциональных разделах модуля управления деятельностью учреждения Системы должна быть предусмотрена возможность ведения справочников и карточек сущностей, соответствующих предметной области конкретного раздела. Справочники должны обеспечивать хранение, просмотр, поиск, фильтрацию, сортировку и актуализацию записей, а карточки сущностей — хранение, отображение и изменение структурированных сведений об объектах учета, документах, задачах, событиях, операциях и иных сущностях, предусмотренных функциональностью раздела. Состав реквизитов справочников и карточек, правила их заполнения и порядок отображения определяются функциональным назначением соответствующего разделах модуля управления деятельностью учреждения и требованиями Заказчика. Статусы и жизненные циклы Для сущностей, используемых в функциональных разделах модуля управления деятельностью учреждения Системы, должны быть предусмотрены статусы и/или жизненные циклы, отражающие этапы их создания, обработки, согласования, исполнения, завершения, архивного хранения либо иного состояния. Изменение статусов должно осуществляться в соответствии с установленными правилами, маршрутами согласования, пользовательскими полномочиями или логикой соответствующего процесса. Система должна обеспечивать фиксацию текущего статуса сущности, историю его изменения, а также возможность использования статусов в механизмах поиска, фильтрации, контроля сроков, отчетности и интеграционного обмена - - Значение характеристики не может изменяться участником закупки - Общие функциональные требования ко всем разделам 2 - Вложения, версии документов Во всех разделах модуля управления деятельностью учреждения, где это требуется по функциональному назначению, должна быть предусмотрена возможность прикрепления вложений и работы с документами, связанными с объектами учета, задачами, поручениями, карточками, реестрами или иными сущностями. Система должна обеспечивать хранение вложенных файлов, их привязку к соответствующим сущностям, а также, при необходимости, ведение версий документов и истории изменений. Для документов и вложений должны быть предусмотрены механизмы контроля актуальности, доступа, замены, загрузки новых редакций и хранения связанной информации о пользователях, выполнивших соответствующие действия. Контроль сроков, уведомления, эскалации Во всех функциональных разделах модуля управления деятельностью учреждения Системы, где предусмотрены процессы с контрольными, плановыми, регламентными или предельными сроками, должна быть реализована возможность контроля таких сроков. Система должна обеспечивать автоматическое отслеживание наступления контрольных событий, формирование уведомлений пользователям, напоминаний о приближении сроков, а также эскалаций при риске нарушения либо факте нарушения установленных сроков в соответствии с принятыми регламентами Заказчика. Правила уведомлений, напоминаний и эскалаций определяются логикой соответствующего раздела модуля управления деятельностью учреждения , установленными маршрутами процессов и требованиями Заказчика - - Значение характеристики не может изменяться участником закупки - Общие функциональные требования ко всем разделам 3 - Отчетность и экспорт Во всех функциональных разделах модуля управления деятельностью учреждения Системы, которые предполагают за собой наличие «полезной» информации для Заказчика, должна быть предусмотрена возможность формирования отчетности по данным, объектам учета, статусам, срокам, результатам исполнения, действиям пользователей или иным сведениям, необходимым для решения задач соответствующего подразделения. Система должна обеспечивать формирование отчетных представлений, выгрузку справочников, карточек, журналов, аналитических выборок и иных данных в объеме, предусмотренном функциональностью конкретного раздела. Состав отчетности, форматы экспорта и объем доступных пользователю данных определяются назначением раздела модуля управления деятельностью учреждения, правами доступа и требованиями Заказчика. Аудит и история изменений Во всех функциональных разделах модуля управления деятельностью учреждения Системы должна быть предусмотрена фиксация действий пользователей и истории изменений по ключевым сущностям, объектам учета, документам, статусам, маршрутам, срокам и иным данным, изменение которых имеет значение для контроля и прослеживаемости процессов. Система должна обеспечивать хранение сведений о создании, изменении, удалении, согласовании, исполнении, передаче, назначении и иных действиях, совершаемых пользователями в рамках работы с данными и объектами системы. Состав фиксируемых событий, глубина хранения истории и доступ к журналам аудита определяются функциональным назначением раздела, требованиями информационной безопасности и правилами администрирования системы - - Значение характеристики не может изменяться участником закупки - Раздел «Интеграция со смежными системами» - Интеграция с АЗД Раздел должен обеспечивать двустороннюю интеграцию с системой автоматизации закупочной деятельности (АЗД) для обмена данными по закупкам, контрактам, этапам исполнения и финансовым резервам. Данная функциональность необходима для синхронизации финансовых и закупочных данных, контроля исполнения обязательств и предотвращения несоответствия данных между системами. Функциональность должна включать: получение данных по заявкам и закупкам из АЗД; получение данных по контрактам и этапам исполнения; получение данных о финансовых резервах и обязательствах; синхронизацию статусов закупок и финансовых резервов; протоколирование операций обмена; контроль ошибок при обмене; возможность повторной обработки данных при сбоях. Интеграция с СЭД «Практика» Раздел должен обеспечивать интеграционное взаимодействие с системой электронного документооборота «Практика» в части получения, передачи и актуализации данных, связанных с документами, резолюциями, поручениями, исполнителями и сроками исполнения. Данная функциональность необходима для синхронизации управленческих процессов между системой и действующим контуром электронного документооборота. Функциональность должна включать: получение документов из СЭД «Практика»; передачу документов в СЭД «Практика»; получение резолюций из СЭД «Практика»; передачу резолюций и связанных данных; синхронизацию карточек документов; синхронизацию карточек поручений; синхронизацию исполнителей; синхронизацию сроков исполнения; получение актуальных статусов документов; получение актуальных статусов поручений; отображение статуса документа на основе данных СЭД «Практика»; отображение статуса поручения на основе данных СЭД «Практика»; передачу результатов исполнения обратно в СЭД «Практика»; передачу подтверждающих материалов; фиксацию результатов обмена данными; контроль корректности интеграционного взаимодействия - - Значение характеристики не может изменяться участником закупки - Раздел «Работа ПИДК» - Статусы работы ИДК Раздел «Работа ПИДК» должен обеспечивать ведение и отображение статусов работы ПИДК в рамках единого информационного контура. Данная функциональность предназначена для оперативного контроля текущего состояния ПИДК, фиксации изменений в работе и предоставления пользователям актуальной информации о статусе объектов и связанных с ними процессов. Система должна обеспечивать возможность присвоения, изменения и отображения статусов работы ПИДК, а также использования этих статусов в механизмах поиска, фильтрации, контроля задач и формирования отчетности. Функциональность должна включать: ведение справочника статусов работы ПИДК; присвоение статуса объекту ПИДК; изменение текущего статуса ПИДК; отображение текущего статуса в карточке ПИДК; фиксацию истории изменения статусов; использование статусов при поиске и фильтрации; использование статусов в отчетности; контроль переходов между статусами; фиксацию даты и времени смены статуса; фиксацию пользователя, выполнившего изменение статуса. Задачи обслуживания ИДК Раздел должен обеспечивать постановку, сопровождение и контроль задач, связанных с обслуживанием ПИДК. Данная функциональность предназначена для организации работ по эксплуатации, техническому сопровождению и поддержанию ПИДК в работоспособном состоянии, а также для контроля сроков и результатов выполнения таких задач - - Значение характеристики не может изменяться участником закупки - Раздел «Работа ПИДК» 2 - Система должна обеспечивать регистрацию задач обслуживания, назначение исполнителей, фиксацию сроков, статусов и результатов выполнения, а также хранение связанной информации и подтверждающих материалов. Функциональность должна включать: создание задач обслуживания ПИДК; указание типа задачи; указание объекта ПИДК, к которому относится задача; описание содержания задачи; назначение исполнителя; назначение ответственного лица; указание планового срока выполнения; указание приоритета задачи; изменение статуса задачи; контроль сроков исполнения; формирование уведомлений по задачам; формирование напоминаний о приближении срока; формирование эскалаций при просрочке; фиксацию результатов выполнения задачи; прикрепление документов, комментариев и иных материалов; хранение истории выполнения задачи; отображение текущего состояния задач обслуживания. Отчетность по работе ИДК Раздел должен обеспечивать формирование отчетности по состоянию ПИДК, статусам работы, задачам обслуживания и результатам их выполнения. Данная функциональность предназначена для получения пользователями и руководством сводной информации о текущем состоянии объектов ПИДК, качестве и своевременности обслуживания, а также для последующего анализа и контроля. Система должна обеспечивать формирование отчетных и аналитических представлений на основании данных раздела с возможностью отбора информации по заданным параметрам. Функциональность должна включать: формирование отчетности по статусам работы ПИДК; формирование отчетности по задачам обслуживания; формирование отчетности по срокам исполнения задач; формирование отчетности по просроченным задачам; формирование отчетности по исполнителям; формирование отчетности по объектам ПИДК; формирование аналитических выборок за заданный период; использование фильтров при формировании отчетности; выгрузку отчетов в установленных форматах; представление отчетной информации в виде, удобном для последующего анализа - - Значение характеристики не может изменяться участником закупки - Раздел «Потребности ГКО» - Список потребностей ГКО Раздел «Потребности ГКО» должен обеспечивать ведение перечня потребностей ГКО в рамках единого информационного пространства. Данная функциональность предназначена для централизованного учета заявленных потребностей, упорядочивания работы с ними и предоставления пользователям актуальной информации о текущем состоянии исполнения. Система должна обеспечивать формирование и ведение списка потребностей с возможностью просмотра, поиска, фильтрации и использования сведений о потребностях в контрольных, исполнительских и отчетных сценариях. Функциональность должна включать: ведение списка потребностей ГКО; создание карточки потребности; отображение основных реквизитов потребности; указание инициатора потребности; указание ответственного лица; указание подразделения; указание описания потребности; указание даты создания; указание текущего статуса; поиск потребностей по основным реквизитам; фильтрацию потребностей по статусам; фильтрацию потребностей по ответственным лицам; фильтрацию потребностей по срокам; отображение истории изменений по потребности; использование списка потребностей при формировании отчетности. Создание потребности Раздел должен обеспечивать регистрацию новых потребностей ГКО и их последующее включение в общий контур учета и исполнения. Данная функциональность предназначена для формализации процесса инициирования потребности, фиксации ее параметров и обеспечения возможности дальнейшего контроля выполнения - - Значение характеристики не может изменяться участником закупки - Раздел «Потребности ГКО» 2 - Создание потребности должно осуществляться с заполнением обязательных реквизитов и последующей передачей потребности в работу в соответствии с установленной логикой разделя. Функциональность должна включать: создание новой потребности; заполнение карточки потребности; указание наименования потребности; указание описания потребности; указание инициатора; указание ответственного исполнителя; указание подразделения; указание приоритета; указание срока исполнения; прикрепление связанных документов и материалов; сохранение потребности в системе; присвоение начальному статусу; возможность редактирования потребности до передачи в исполнение; фиксацию даты и времени создания; фиксацию пользователя, создавшего потребность. Выполнение потребности Раздел должен обеспечивать сопровождение процесса выполнения потребности ГКО с фиксацией всех значимых действий, этапов и результатов исполнения. Данная функциональность предназначена для контроля исполнения заявленных потребностей и обеспечения прослеживаемости работы по каждой из них. Система должна обеспечивать назначение исполнителей, изменение статусов, фиксацию результатов выполнения и хранение подтверждающих материалов по завершении работ. Функциональность должна включать: передачу потребности в исполнение; назначение исполнителя; назначение соисполнителей при необходимости; изменение статусов в процессе выполнения; фиксацию этапов исполнения; добавление комментариев по ходу выполнения; прикрепление подтверждающих документов и материалов; фиксацию результата выполнения; завершение исполнения потребности; указание причины возврата или невозможности исполнения при необходимости; хранение истории действий по выполнению потребности; отображение текущего состояния исполнения в карточке потребности - - Значение характеристики не может изменяться участником закупки - Раздел «Потребности ГКО» 3 - Контроль статусов и сроков потребностей Раздел должен обеспечивать контроль статусов и сроков исполнения потребностей ГКО. Данная функциональность предназначена для своевременного выявления рисков просрочки, контроля текущего состояния потребностей и информирования ответственных лиц о необходимости выполнения действий. Система должна обеспечивать использование статусов и сроков как инструментов управления исполнением, контроля дисциплины и подготовки отчетной информации. Функциональность должна включать: контроль текущего статуса потребности; контроль сроков исполнения потребности; фиксацию плановой даты исполнения; фиксацию фактической даты исполнения; формирование уведомлений о приближении срока; формирование напоминаний ответственным лицам; формирование эскалаций при риске просрочки; формирование эскалаций при факте просрочки; использование статусов и сроков в поиске и фильтрации; использование статусов и сроков в отчетности; отображение просроченных потребностей; отображение потребностей, требующих внимания пользователя - - Значение характеристики не может изменяться участником закупки - Раздел «База знаний» - Список документов и инструкций Раздел «База знаний» должен обеспечивать централизованное ведение перечня документов, инструкций и иных информационных материалов, используемых в деятельности Заказчика. Данная функциональность предназначена для предоставления пользователям единой точки доступа к актуальным нормативным, методическим и справочным материалам, необходимым для выполнения служебных обязанностей. Система должна обеспечивать формирование структурированного списка документов и инструкций с возможностью поиска, просмотра, фильтрации и последующего использования материалов в рамках рабочих процессов. Функциональность должна включать: ведение списка документов и инструкций; создание карточки документа или инструкции; указание наименования документа; указание категории или типа документа; указание даты размещения; указание статуса актуальности; указание ответственного за материал; привязку документа к тематике, подразделению или направлению деятельности; поиск документов по наименованию и основным реквизитам; фильтрацию документов по категориям, статусам и иным признакам; просмотр карточки документа; переход к содержимому документа или вложенному файлу - - Значение характеристики не может изменяться участником закупки - Раздел «База знаний» 2 - Хранение и актуализация материалов Раздел должен обеспечивать хранение материалов базы знаний, их актуализацию и сопровождение в процессе эксплуатации системы. Данная функциональность предназначена для поддержания базы знаний в актуальном состоянии, контроля версий материалов и обеспечения пользователей достоверной информацией. Система должна обеспечивать хранение файлов, текстовых материалов и связанных данных, а также фиксацию изменений, выполняемых в отношении документов и инструкций. Функциональность должна включать: загрузку документов и инструкций в систему; хранение файлов и материалов; обновление ранее размещенных материалов; замену неактуальных версий документов; хранение истории изменений; ведение версий материалов; фиксацию даты актуализации; фиксацию пользователя, внесшего изменение; изменение статуса актуальности материала; архивирование устаревших материалов; контроль доступности пользователям только актуальных материалов в пределах заданной логики; прикрепление сопроводительных файлов и комментариев при необходимости. Опросы Раздел должен обеспечивать создание, проведение и сопровождение опросов пользователей по тематике, связанной с документами, инструкциями, внутренними регламентами и иными материалами базы знаний. Данная функциональность предназначена для сбора обратной связи, проверки ознакомления с материалами и получения сведений, необходимых для внутреннего контроля и анализа. Система должна обеспечивать подготовку опросов, определение состава участников, фиксацию ответов и хранение результатов прохождения. Функциональность должна включать: создание опросов; указание наименования опроса; формирование перечня вопросов; настройку вариантов ответов; определение целевой аудитории опроса; назначение сроков прохождения; публикацию опроса для пользователей; сбор ответов пользователей; фиксацию даты и времени прохождения; хранение результатов опроса; повторное проведение опроса при необходимости; использование результатов опросов в отчетности - - Значение характеристики не может изменяться участником закупки - Раздел «База знаний» 3 - Тестирование Раздел должен обеспечивать проведение тестирования пользователей по материалам базы знаний, внутренним инструкциям, регламентам и иным документам, размещенным в системе. Данная функциональность предназначена для проверки уровня ознакомления пользователей с материалами, контроля усвоения информации и подтверждения прохождения обязательных процедур. Система должна обеспечивать формирование тестов, назначение их пользователям или группам пользователей, фиксацию результатов прохождения и хранение истории тестирования. Функциональность должна включать: создание тестов; формирование набора вопросов для тестирования; настройку правильных ответов; определение правил прохождения теста; назначение тестирования пользователям; назначение тестирования группам пользователей; указание срока прохождения теста; фиксацию факта начала тестирования; фиксацию факта завершения тестирования; расчет результата прохождения; отображение результата пользователю; хранение истории прохождения тестов; повторное назначение тестирования при необходимости - - Значение характеристики не может изменяться участником закупки - Раздел «База знаний» 4 - Отчетность по прохождению опросов и тестирования Раздел должен обеспечивать формирование отчетности по прохождению опросов и тестирования пользователями. Данная функциональность предназначена для контроля исполнительской дисциплины, анализа результатов и предоставления руководству и ответственным лицам сведений о степени прохождения материалов и проверочных мероприятий. Система должна обеспечивать формирование отчетных и аналитических представлений на основании накопленных данных по опросам и тестам с возможностью отбора информации по пользователям, подразделениям, срокам и результатам. Функциональность должна включать: формирование отчетности по прохождению опросов; формирование отчетности по прохождению тестирования; отображение списка пользователей, прошедших опрос; отображение списка пользователей, не прошедших опрос; отображение списка пользователей, прошедших тестирование; отображение списка пользователей, не прошедших тестирование; формирование отчетности по срокам прохождения; формирование отчетности по результатам тестирования; формирование аналитики по подразделениям; формирование аналитики по группам пользователей; использование фильтров при подготовке отчетов; выгрузку отчетных данных в установленных форматах - - Значение характеристики не может изменяться участником закупки - Раздел «Дашборд и навигация между модулями» - Стартовая страница Раздел дашборда должен обеспечивать пользователю единый интерфейс для доступа к основным функциональным модулям системы и сводной информации. Данная функциональность предназначена для упрощения навигации, повышения оперативности доступа к ключевым данным и контроля состояния процессов в разных модулях. Функциональность должна включать: отображение сводной информации по состоянию ключевых показателей (KPI) и задач; визуализацию состояния процессов по модулям; доступ к отдельным функциональным блокам модулей по нажатию на соответствующие элементы интерфейса; возможность расширения и группировки блоков в раздел «В разработке» для модулей, находящихся в стадии внедрения; адаптивное отображение для разных устройств (ПК, планшет, мобильный телефон); предоставление краткой аналитической информации по каждому модулю на стартовой странице; поддержку интерактивного перехода к модулям с сохранением единой авторизации - - Значение характеристики не может изменяться участником закупки - Раздел «Дашборд и навигация между модулями» 2 - Модульные блоки Модульные блоки дашборда должны представлять собой визуальные элементы, отражающие доступные функциональные модули и их текущее состояние. Данная функциональность предназначена для быстрого выбора и перехода к интересующим модулям, а также для обеспечения наглядного контроля над рабочими процессами. Функциональность должна включать: отображение блоков по каждому модулю; выделение модулей, находящихся в стадии внедрения, с указанием статуса «В разработке»; возможность перехода к модулю из блока дашборда; группировку блоков по категориям или состоянию разработки; отображение уведомлений о критических событиях или сроках в рамках модуля; настройку порядка и размера блоков на странице; поддержку интерактивного расширения групп модулей; единый стиль отображения для всех модулей с сохранением единых UI-паттернов - - Значение характеристики не может изменяться участником закупки - Раздел «Пресс?служба» - Сбор и парсинг новостей Раздел пресс-службы должен обеспечивать автоматизированный мониторинг информационного поля по заданным источникам с последующим сбором и обработкой новостных публикаций. Функциональность данного подпункта предназначена для сокращения доли ручной работы сотрудников пресс-службы, повышения полноты мониторинга и обеспечения оперативного выявления значимых информационных сообщений. Система должна обеспечивать получение новостных публикаций из определенного перечня источников, извлечение значимых атрибутов публикации и сохранение результатов мониторинга для дальнейшей классификации, анализа и работы сотрудников пресс-службы. Функциональность должна включать: автоматический сбор новостей из заранее определенного перечня источников; получение данных с сайтов СМИ, официальных сайтов ведомств, официальных каналов, RSS-лент и иных источников, определенных Заказчиком; обработку новостных публикаций по заданной периодичности; парсинг заголовка публикации; парсинг текста публикации; парсинг даты и времени публикации; парсинг сведений об авторе публикации при наличии; парсинг сведений об источнике публикации; сохранение ссылки на первоисточник; исключение либо отметку дублирующихся публикаций при повторном обнаружении; сохранение результатов сбора в системе для последующего анализа и обработки - - Значение характеристики не может изменяться участником закупки - Раздел «Пресс?служба» 2 - Настройка источников мониторинга Раздел должен обеспечивать настройку и сопровождение источников, используемых для автоматического мониторинга новостей. Указанная функциональность необходима для гибкого управления перечнем отслеживаемых ресурсов и параметрами получения информации в зависимости от задач пресс-службы. Настройка источников мониторинга должна обеспечивать возможность изменения состава отслеживаемых ресурсов, определения периодичности опроса и задания параметров, влияющих на поиск, отбор и дальнейшую обработку публикаций. Функциональность должна включать: добавление новых источников мониторинга; изменение параметров ранее добавленных источников; отключение и повторное включение источников мониторинга; указание URL или иного идентификатора источника; настройку периодичности опроса источника; привязку источника к категориям мониторинга; указание ключевых слов и поисковых условий; настройку принадлежности источника к тематике, региону, организации или иному классификационному признаку; ведение перечня активных и неактивных источников; хранение параметров настройки по каждому источнику - - Значение характеристики не может изменяться участником закупки - Раздел «Пресс?служба» 3 - Классификация новостей Раздел должен обеспечивать классификацию новостных публикаций по признакам, необходимым для анализа информационного поля, последующей фильтрации данных и формирования отчетности. Классификация должна использоваться как для автоматизированной обработки публикаций, так и для поддержки аналитической работы сотрудников пресс-службы. Результаты классификации должны сохраняться в системе и использоваться при поиске, фильтрации, группировке публикаций и подготовке аналитических материалов. Функциональность должна включать: классификацию публикаций по темам; классификацию публикаций по регионам; классификацию публикаций по организациям; классификацию публикаций по уровню значимости; возможность автоматического присвоения классификационных признаков по заданным правилам; возможность ручной корректировки классификации пользователем; использование классификационных признаков в поиске, фильтрации, отчетности и аналитике; сохранение результатов классификации в карточке публикации - - Значение характеристики не может изменяться участником закупки - Раздел «Пресс?служба» 4 - Ручная загрузка новостей Раздел должен обеспечивать возможность ручного внесения новостных публикаций в систему в случаях, когда информация не была получена автоматически либо должна быть добавлена сотрудником пресс-службы отдельно. Такая функциональность необходима для обеспечения полноты учета и сохранения в системе всех значимых публикаций, подлежащих рассмотрению и анализу. Ручное добавление новостей должно осуществляться в рамках общей логики работы раздела с возможностью последующего редактирования, классификации, анализа и использования публикации в отчетности. Функциональность должна включать: создание карточки новости вручную; ввод заголовка публикации; ввод текста публикации; указание даты публикации; указание автора при наличии; указание источника публикации; добавление ссылки на первоисточник при наличии; присвоение тематических и иных классификационных признаков; прикрепление файлов и сопроводительных материалов при необходимости; сохранение вручную добавленных новостей в общем контуре мониторинга; возможность последующего редактирования вручную добавленной информации в рамках установленных прав доступа - - Значение характеристики не может изменяться участником закупки - Раздел «Пресс?служба» 5 - История мониторинга и действия пресс?службы по публикациям Раздел должен обеспечивать накопление и хранение истории работы с публикациями, начиная с момента их обнаружения или загрузки в систему и заканчивая обработкой сотрудниками пресс-службы. Указанная функциональность необходима для обеспечения прослеживаемости действий, анализа реакции на публикации и формирования полной картины работы по каждому информационному сообщению. История публикации должна отражать изменения ее состояния, действия пользователей, результаты анализа и иные сведения, связанные с рассмотрением и сопровождением публикации в системе. Функциональность должна включать: хранение истории поступления публикации в систему; фиксацию даты и времени обнаружения публикации; сохранение истории изменений карточки публикации; ведение истории классификации и переклассификации; фиксацию действий сотрудников пресс-службы по публикации; хранение отметок о рассмотрении публикации; хранение комментариев, решений, служебных пометок и иных сведений по публикации; возможность просмотра аналитики по публикации; сохранение истории связанных действий и событий в карточке публикации; использование истории публикации для последующего анализа и отчетности - - Значение характеристики не может изменяться участником закупки - Раздел «Пресс?служба» 6 - Экспорт отчетов Раздел должен обеспечивать формирование отчетности по результатам мониторинга и возможность выгрузки подготовленных материалов в распространенные форматы. Указанная функциональность предназначена для подготовки аналитических материалов, служебной отчетности и предоставления сведений руководству и заинтересованным подразделениям. Отчетность должна формироваться на основании данных, накопленных в системе, с учетом параметров поиска, фильтрации, классификации и аналитических признаков публикаций. Функциональность должна включать: формирование отчетов по собранным публикациям; формирование отчетов по источникам мониторинга; формирование отчетов по темам, регионам, организациям и уровням значимости; формирование отчетов по действиям пресс-службы; формирование аналитических выборок за заданный период; применение фильтров при формировании отчетов; выгрузку отчетов в формат Excel; выгрузку отчетов в формат PDF; возможность экспорта данных по результатам поиска и фильтрации; сохранение сформированных отчетов в системе при необходимости - - Значение характеристики не может изменяться участником закупки - Раздел «Безопасность и гражданская оборона» - Оповещение и экстренный обзвон сотрудников Раздел безопасности и гражданской обороны должен обеспечивать оперативное оповещение сотрудников при возникновении чрезвычайных, аварийных, эвакуационных и иных значимых событий. Данная функциональность предназначена для централизованной организации экстренного информирования работников и сокращения времени доведения информации до ответственных лиц и групп реагирования через мобильное приложение «АСУР». Система должна обеспечивать выполнение сценариев массового и адресного оповещения с использованием функциональных средств «АСУР» или иных каналов информирования, предусмотренных составом внедряемой функциональности. Функциональность должна включать: запуск оповещения по заранее определенным спискам получателей; формирование и использование перечней сотрудников для оповещения; фиксацию факта направления оповещения; фиксацию статуса доставки или результата оповещения в пределах технически доступных возможностей; сохранение истории проведенных оповещений; отображение информации о текущем и завершенном оповещении. Сценарии оповещения по типам событий Раздел должен обеспечивать формирование и использование сценариев оповещения в зависимости от типа события, характера угрозы, состава вовлеченных подразделений и категорий получателей. Указанная функциональность необходима для стандартизации действий при различных ситуациях и сокращения времени подготовки оповещения. Сценарии оповещения должны задавать состав получателей, порядок использования каналов связи, текстовое или голосовое содержание сообщений, а также правила дальнейшего информирования и эскалации - - Значение характеристики не может изменяться участником закупки - Раздел «Безопасность и гражданская оборона» 2 - Функциональность должна включать: создание сценариев оповещения по типам событий; настройку сценариев для событий, связанных с пожаром; настройку сценариев для событий, связанных с эвакуацией; настройку сценариев для событий, связанных с техногенными авариями; настройку сценариев для иных типов событий, определяемых Заказчиком; привязку сценария к составу получателей; привязку сценария к приоритетам оповещения; настройку каналов оповещения в рамках сценария; хранение параметров сценариев; возможность изменения и актуализации сценариев. Запуск обзвона Раздел должен обеспечивать запуск обзвона и оповещения как по инициативе пользователя, так и по заранее установленным условиям, правилам и событиям. Такая функциональность необходима для поддержки как оперативного реагирования, так и регламентных действий, выполняемых без ручного участия оператора. Запуск обзвона должен учитывать выбранный сценарий, состав получателей, приоритетность групп, используемые каналы оповещения и иные параметры, определенные в настройках системы. Функциональность должна включать: запуск обзвона в ручном режиме; запуск обзвона в автоматическом режиме; использование заранее настроенных регламентных триггеров; выбор сценария оповещения при запуске; выбор групп или отдельных получателей; фиксацию даты и времени запуска обзвона; отображение текущего состояния процесса оповещения; сохранение результатов выполнения обзвона; возможность остановки, повторного запуска или продолжения процедуры оповещения в рамках предусмотренной логики - - Значение характеристики не может изменяться участником закупки - Раздел «Безопасность и гражданская оборона» 3 - Голосовые шаблоны сообщений Раздел должен обеспечивать использование заранее подготовленных голосовых шаблонов сообщений для автоматизированного обзвона и информирования сотрудников. Указанная функциональность необходима для стандартизации содержания сообщений, сокращения времени на подготовку оповещения и обеспечения единообразного доведения информации до получателей. Голосовые шаблоны должны использоваться в рамках сценариев оповещения и быть доступны для выбора, привязки и изменения в соответствии с полномочиями пользователей. Функциональность должна включать: создание голосовых шаблонов сообщений; хранение голосовых шаблонов в системе; выбор голосового шаблона при настройке сценария; привязку шаблона к типу события; использование шаблона при запуске обзвона; изменение и актуализацию шаблонов; хранение нескольких вариантов шаблонов для разных сценариев; использование шаблонов для массового и адресного оповещения. Каскадный обзвон по приоритетным группам Раздел должен обеспечивать каскадный обзвон сотрудников с учетом заранее определенной очередности групп и приоритетов информирования. Такая функциональность необходима для соблюдения установленного порядка оповещения, в котором сначала информируются наиболее критичные категории получателей, а затем остальные участники процесса. Каскадный обзвон должен использоваться для организации поэтапного доведения информации до руководства, дежурных служб, ответственных лиц, сотрудников объектов и иных групп, определяемых Заказчиком. Функциональность должна включать: настройку приоритетных групп получателей; задание очередности обзвона групп; запуск обзвона по каскадной схеме; выделение групп руководства; выделение групп дежурных служб; выделение групп сотрудников объектов; переход к следующей группе в соответствии с настроенной логикой; фиксацию результатов оповещения по каждой группе; использование каскадного обзвона в рамках сценариев оповещения - - Значение характеристики не может изменяться участником закупки - Раздел «Безопасность и гражданская оборона» 4 - Альтернативные каналы Раздел должен обеспечивать использование альтернативных каналов информирования в случаях, когда основной способ оповещения недоступен, недостаточен либо требует дублирования сообщения. Указанная функциональность предназначена для повышения надежности системы оповещения и обеспечения доставки информации до получателей в различных условиях. Альтернативные каналы могут использоваться как резервный или дополнительный способ уведомления в составе единого сценария оповещения. Функциональность должна включать: использование резервных каналов информирования; использование нескольких каналов в рамках одного сценария; отправку сообщений по альтернативному каналу при недоступности основного; отправку уведомлений по SMS; отправку уведомлений по электронной почте; отправку push-уведомлений; фиксацию факта использования альтернативного канала; сохранение результатов доставки или попытки доставки в пределах технически доступных возможностей; настройку логики переключения между каналами оповещения - - Значение характеристики не может изменяться участником закупки - Раздел «Управление информационных технологий» - Раздел персональных данных и согласий Раздел Управления информационных технологий в части персональных данных должен обеспечивать централизованный учет сведений о субъектах персональных данных, основаниях их обработки, согласиях на обработку и передачу данных, а также связанных с этим действиях пользователей и системы. Данная функциональность предназначена для упорядочивания работы с персональными данными, обеспечения прослеживаемости операций и снижения рисков неконтролируемой обработки сведений. Раздел должен использоваться для ведения структурированных данных о составе обрабатываемых персональных данных, статусах согласий, сроках хранения, действиях с данными и основаниях обработки, а также для последующего контроля, аудита и исполнения процедур, связанных с отзывом согласия. Функциональность должна включать: ведение справочника субъектов персональных данных; ведение сведений о категориях субъектов персональных данных; ведение сведений о составе хранимых персональных данных; учет категорий персональных данных; учет правовых оснований обработки персональных данных; учет сроков хранения персональных данных; регистрацию согласий на обработку персональных данных; регистрацию согласий на передачу персональных данных; хранение согласий в системе; ведение версий согласий; отображение текущего статуса согласия; фиксацию статуса «действует»; фиксацию статуса «отозвано»; фиксацию статуса «истекло»; контроль операций с персональными данными; учет операций просмотра; учет операций изменения; учет операций выгрузки; учет операций удаления; учет операций обезличивания; ведение журнала аудита по персональным данным; фиксацию сведений о пользователе, выполнившем операцию; фиксацию даты и времени операции; фиксацию состава обработанных данных; фиксацию основания обработки - - Значение характеристики не может изменяться участником закупки - Раздел «Управление информационных технологий» 2 - Учет учетных записей и телефонный справочник Раздел должен обеспечивать ведение сведений об учетных записях пользователей и сопровождение корпоративного телефонного справочника. Данная функциональность предназначена для централизованного учета учетных записей, их статусов, связи с сотрудниками и подразделениями, а также для предоставления актуальной справочной информации, используемой в повседневной работе пользователей и в функциональных сценариях других разделах. Система должна обеспечивать ведение структурированных сведений об учетных записях, их жизненном цикле, принадлежности к сотрудникам и организационной структуре, а также поддержку поиска и использования контактных данных в справочном и прикладном режимах. Функциональность должна включать: ведение справочника учетных записей; регистрацию учетных записей; изменение учетных записей; блокировку учетных записей; архивирование учетных записей; привязку учетной записи к сотруднику; привязку учетной записи к подразделению; привязку учетной записи к роли; привязку учетной записи к полномочиям; фиксацию статуса учетной записи; отображение статуса «активна»; отображение статуса «временно заблокирована»; отображение статуса «деактивирована»; ведение корпоративного телефонного справочника; хранение ФИО; хранение должности; хранение подразделения; хранение контактных данных; поиск по сотруднику; поиск по подразделению; поиск по должности; поиск по номеру телефона; актуализацию сведений справочника; использование справочных данных в иных модулях Системы - - Значение характеристики не может изменяться участником закупки - Раздел «Управление информационных технологий» 3 - Автоматические действия при отзыве согласия Раздел должен обеспечивать автоматизированную обработку событий, связанных с отзывом согласия субъекта персональных данных, в пределах логики, допустимой действующими правилами обработки данных и внутренними регламентами Заказчика. Данная функциональность предназначена для сокращения ручных операций, повышения управляемости процессов прекращения обработки и обеспечения фиксации результатов выполненных действий. После регистрации отзыва согласия система должна обеспечивать запуск предусмотренных процедур в отношении соответствующих персональных данных, включая ограничение дальнейшей обработки, формирование задач, фиксацию статусов и выполнение последующих операций в зависимости от настроенной логики и оснований обработки. Функциональность должна включать: регистрацию события отзыва согласия; запуск процедуры обработки последствий отзыва; проверку наличия оснований для дальнейшей обработки данных; ограничение дальнейших операций с персональными данными при отсутствии оснований; запуск процедуры прекращения обработки персональных данных; инициирование удаления персональных данных в допустимых случаях; инициирование обезличивания персональных данных в допустимых случаях; формирование задач ответственным пользователям при необходимости ручной обработки; фиксацию даты запуска процедуры; фиксацию основания выполнения действий; фиксацию перечня обработанных данных; фиксацию результата выполнения процедуры; хранение подтверждения исполнения отзыва; отображение статуса исполнения действий по отзыву согласия; сохранение истории всех связанных операций в журнале аудита - - Значение характеристики не может изменяться участником закупки - Раздел «Административное управление» - Учет материальных ценностей Раздел административного управления должен обеспечивать централизованный учет материальных ценностей в рамках единого информационного пространства. Данная функциональность предназначена для систематизации сведений о материальных ценностях, контролю их состояния, местонахождения, ответственных лиц и истории движения. Система должна обеспечивать ведение карточек материальных ценностей, учет количественных и стоимостных характеристик, фиксацию статусов и сопровождение операций, связанных с жизненным циклом каждой единицы учета. Функциональность должна включать: ведение единого справочника материальных ценностей; формирование карточки материальной ценности; присвоение инвентарных номеров; присвоение учетных номеров; классификацию материальных ценностей по типам; учет количественных показателей; учет стоимостных показателей; учет состояния материальной ценности; учет местонахождения материальной ценности; учет закрепления за сотрудниками; учет закрепления за подразделениями; фиксацию ответственных лиц; хранение истории операций по каждой единице учета; формирование первичных учетных форм; формирование отчетов по движению материальных ценностей - - Значение характеристики не может изменяться участником закупки - Раздел «Административное управление» 2 - Выдача и передача материальных ценностей Раздел должен обеспечивать сопровождение процессов выдачи, возврата и передачи материальных ценностей между сотрудниками, подразделениями и материально ответственными лицами. Данная функциональность предназначена для контроля движения материальных ценностей, подтверждения оснований передачи и фиксации текущего держателя каждой единицы учета. Система должна обеспечивать оформление операций передачи, хранение сопроводительных документов и контроль сроков временной выдачи с возможностью формирования уведомлений и последующего анализа движения материальных ценностей. Функциональность должна включать: оформление заявок на выдачу материальных ценностей; поддержку маршрутов согласования заявок; регистрацию операций выдачи; регистрацию операций возврата; регистрацию операций передачи между подразделениями; регистрацию операций передачи между материально ответственными лицами; контроль оснований выдачи; контроль оснований передачи; учет заявки как основания выдачи; учет приказа как основания выдачи; учет акта как основания передачи; формирование актов приема-передачи; хранение актов приема-передачи; хранение сопроводительных документов; контроль сроков временной выдачи; формирование уведомлений о сроках возврата; отслеживание текущего держателя материальной ценности; отслеживание текущего статуса материальной ценности - - Значение характеристики не может изменяться участником закупки - Раздел «Административное управление» 3 - Инвентаризация Раздел должен обеспечивать планирование, проведение и фиксацию результатов инвентаризации материальных ценностей. Данная функциональность предназначена для проверки фактического наличия материальных ценностей, выявления расхождений с учетными данными и документирования итогов инвентаризационных мероприятий. Система должна обеспечивать формирование инвентаризационных ведомостей, учет результатов проверки, фиксацию излишков, недостач и иных расхождений, а также подготовку итоговых документов и аналитической отчетности. Функциональность должна включать: планирование плановых инвентаризаций; планирование внеплановых инвентаризаций; проведение инвентаризаций по подразделениям; проведение инвентаризаций по локациям; проведение инвентаризаций по материально ответственным лицам; формирование инвентаризационных ведомостей; фиксацию фактического наличия материальных ценностей; фиксацию состояния материальных ценностей; фиксацию расхождений с учетными данными; оформление результатов инвентаризации; учет излишков; учет недостач; учет пересортицы; оформление списания; оформление доначисления; поддержку фотофиксации; прикрепление подтверждающих документов; формирование итоговых актов; формирование аналитической отчетности по результатам инвентаризации - - Значение характеристики не может изменяться участником закупки - Раздел «Управление закупок» - Централизованная консолидация данных Раздел управления закупок должен обеспечивать централизованное получение, сведение и консолидацию финансовых данных из всех модулей и разделов Системы и смежных информационных систем. Данная функциональность предназначена для формирования единого контура закупочного учета, сопоставимости показателей между управлениями и прозрачности финансовых потоков. Функциональность должна включать: сбор финансовых данных из модулей и разделов; сведение данных в единую структуру для сопоставимости; консолидацию плановых данных; консолидацию фактических данных; анализ данных по управлению, объекту, статье, периоду и источнику финансирования; формирование сводного финансового баланса по организации. Учет бюджетных обязательств и лимитов Раздел должен обеспечивать ведение лимитов бюджетных обязательств (ЛБО) и контроль их использования в рамках финансового планирования. Данная функциональность предназначена для предотвращения превышения бюджетных лимитов, контроля кассового плана и соблюдения бюджетной дисциплины - - Значение характеристики не может изменяться участником закупки - Раздел «Управление закупок» 2 - Функциональность должна включать: ведение лимитов бюджетных обязательств по периодам и направлениям; резервирование лимитов при инициации закупки; корректировку лимитов по факту исполнения; автоматическую проверку доступности лимитов при создании финансовых операций; блокировку или перевод на согласование операций при превышении лимита; контроль кассового плана в режиме план/факт. Планирование и план?графики Раздел должен обеспечивать формирование и ведение финансовых планов и план-графиков закупок, а также контроль изменений и отклонений. Данная функциональность предназначена для соблюдения бюджетной дисциплины и согласованного распределения ресурсов. Функциональность должна включать: формирование финансовых планов; формирование план-графиков закупок; учет изменений план-графиков с сохранением истории версий; сверку план-графика с бюджетными параметрами; контроль отклонений от плана; фиксацию причин изменений; хранение истории изменений планов - - Значение характеристики не может изменяться участником закупки - Раздел «Управление закупок» 3 - Контроль и согласование Раздел должен обеспечивать контроль соблюдения правил бюджетной дисциплины, согласование финансовых операций и корректировок бюджета. Данная функциональность необходима для снижения рисков превышения лимитов, несоответствия статьям бюджета и нарушения сроков исполнения. Функциональность должна включать: настройку маршрутов согласования финансовых документов; настройку маршрутов согласования корректировок бюджета; контроль соблюдения бюджетной дисциплины; применение контрольных правил; уведомления ответственных лиц при критических отклонениях; уведомления при риске кассового разрыва; уведомления при нарушении сроков исполнения. Аналитика и отчетность Раздел должен обеспечивать контроль соблюдения правил бюджетной дисциплины, согласование финансовых операций и корректировок бюджета. Данная функциональность необходима для снижения рисков превышения лимитов, несоответствия статьям бюджета и нарушения сроков исполнения. Функциональность должна включать: настройку маршрутов согласования финансовых документов; настройку маршрутов согласования корректировок бюджета; контроль соблюдения бюджетной дисциплины; применение контрольных правил (превышение лимита, несоответствие статьям, дублирование обязательств); уведомления ответственных лиц при критических отклонениях; уведомления при риске кассового разрыва; уведомления при нарушении сроков исполнения - - Значение характеристики не может изменяться участником закупки - Раздел «Управление комплектации и ремонта» - Контроль исполнения задач Раздел управления комплектации и ремонта должен обеспечивать регистрацию, сопровождение и контроль выполнения задач, связанных с работами по обеспечению объектов оборудованием, комплектующими и проведением ремонтных мероприятий. Данная функциональность предназначена для повышения прозрачности процессов, контроля сроков и качества выполнения задач. Функциональность должна включать: создание и ведение задач (тип задачи, объект/локация, описание, приоритет, сроки, ответственные); назначение исполнителей и возможность переназначения с фиксацией причины; формирование исполнительской отчетности по задаче (фотофиксация, прикрепление документов, комментарии); контроль сроков исполнения: план/факт, просрочка, критичность отклонений; автоматические уведомления о ключевых сроках, возвратах и просрочках; эскалация руководителю при нарушении сроков; ведение журнала действий и истории изменений по задаче (аудит); формирование дашбордов и отчетов по дисциплине исполнения, просрочкам, нагрузке по подразделениям и исполнителям; интеграция с АЗД для привязки задач к заявкам/закупкам и получения/передачи статусов. Проверка заявок Раздел должен обеспечивать автоматическую проверку заявок на комплектацию и ремонт. Данная функциональность предназначена для повышения точности проверки, сокращения ошибок и ускорения обработки заявок - - Значение характеристики не может изменяться участником закупки - Раздел «Управление комплектации и ремонта» 2 - Функциональность должна включать: автоматическую проверку полноты комплекта документов (обоснование, КП, ТЗ, расчет НМЦК, план-график); проверку обоснования закупки; сопоставление данных ТЗ и КП (наименование закупки, характеристики, единицы измерения, объемы); контроль срока актуальности КП (не старше установленного периода); проверку реквизитов КП (подпись, дата, ответственное лицо); проверку контрагентов (существование, корректность данных, соответствие по ОКВЭД, проверка по РНП); выявление признаков аффилированности по заданным правилам; проверку бюджетно-классификационных параметров (ЦСР, ВР, КОСГУ, ОКПД-2, сумма, наименование); проверку корректности расчета НМЦК (логические/арифметические несоответствия); сверку заявки с планом-графиком по ключевым реквизитам; формирование результата проверки: список замечаний, уровень критичности, рекомендации по исправлению, решение (допустить/вернуть). Проверка смет Раздел должен обеспечивать автоматизированную проверку сметной документации. Данная функциональность предназначена для выявления типовых ошибок, проверки полноты и корректности структуры смет, а также формирования аналитической информации о качестве смет. Функциональность должна включать: загрузку сметной документации; проверку структуры сметы и полноты обязательных разделов; выявление типовых ошибок и несоответствий; классификацию замечаний по критичности: критичные, существенные, рекомендательные; формирование протокола проверки (ошибка, обоснование, ссылка на раздел/позицию, рекомендация к исправлению); поддержку процесса проверки филиал ? центральный аппарат с возвратом на доработку и повторной проверкой; хранение истории версий смет; хранение истории замечаний и исправлений; формирование аналитической отчетности по качеству смет и повторяемости ошибок - - Значение характеристики не может изменяться участником закупки - Раздел «Реестр событий информационной безопасности» - Реестр событий информационной безопасности Раздел должен обеспечивать ведение единого реестра событий информационной безопасности, связанных с потенциальными и фактическими утечками информации. Данная функциональность предназначена для централизованного учета инцидентов, их анализа и обеспечения прозрачности процессов реагирования. Функциональность должна включать: создание и ведение карточек событий ИБ; указание типа инцидента (утечка, попытка утечки, нарушение политики доступа и др.); указание источника события (пользователь, система, внешнее подключение); фиксацию времени и даты события; указание затронутых информационных ресурсов; классификацию уровня критичности инцидента; назначение ответственных за обработку инцидента; хранение истории изменений и статусов инцидента; возможность фильтрации и поиска событий по ключевым параметрам. Паспорт инцидента информационной безопасности Раздел должен обеспечивать формирование и хранение паспорта инцидента информационной безопасности в структурированном виде. Данная функциональность позволяет централизованно хранить всю информацию по инциденту и контролировать полноту и актуальность данных. Функциональность должна включать: структурированное хранение данных по инциденту; фиксацию описания инцидента; хранение доказательной базы (логи, файлы, скриншоты); хранение результатов расследования; фиксацию принятых мер реагирования; хранение сопутствующих документов; ведение версий паспорта инцидента; контроль актуальности информации; возможность интеграции с системами сбора логов - - Значение характеристики не может изменяться участником закупки - Результаты внедрения модуля - По результатам внедрения модуля Заказчик должен получить единый информационный контур для автоматизации и сопровождения деятельности структурных подразделений, обеспечивающий централизованный доступ к данным, документам, задачам, отчетности и иным объектам учета в рамках установленных полномочий пользователей. Результатами внедрения системы являются: автоматизация ключевых процессов структурных подразделений Заказчика в рамках предусмотренных функциональных модулей; создание единой точки входа пользователей в систему с разграничением прав доступа по ролям и полномочиям; сокращение доли ручных операций при обработке документов, поручений, заявок, справочников, карточек объектов и иных сущностей; повышение прозрачности бизнес-процессов, статусов исполнения, сроков и результатов деятельности подразделений; обеспечение контроля исполнительской дисциплины, сроков исполнения задач, поручений, согласований и процессуальных действий; обеспечение централизованного хранения данных, документов, вложений, версий и истории изменений; повышение достоверности, актуальности и полноты информации, используемой в работе подразделений; обеспечение возможности оперативного поиска, фильтрации, анализа и выгрузки данных; формирование регламентной, аналитической и управленческой отчетности по направлениям деятельности; обеспечение интеграционного взаимодействия с внешними и смежными информационными системами в пределах предусмотренного объема работ; создание условий для дальнейшего развития системы, подключения новых модулей, сервисов и пользовательских сценариев; повышение качества управленческих решений за счет консолидации информации и доступа к актуальным данным в единой системе - - Значение характеристики не может изменяться участником закупки

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

Цели внедрения модуля - Целями внедрения модуля управления деятельностью учреждения являются повышение эффективности управления внутренними процессами Заказчика, формирование единого цифрового пространства для взаимодействия структурных подразделений, обеспечение централизованного учета данных, а также сокращение сроков обработки информации, документов, поручений и управленческих решений. Внедрение модуля должна обеспечить унификацию и формализацию бизнес-процессов, повышение прозрачности исполнения задач и поручений, снижение зависимости от разрозненных информационных ресурсов и ручных операций, а также повышение качества контроля сроков, статусов и результатов деятельности подразделений. Дополнительными целями внедрения являются: обеспечение единой точки входа пользователей в модули системы; создание сквозного контура работы с данными, документами, задачами, отчетностью и интеграциями; автоматизация функциональных процессов подразделений Заказчика; повышение достоверности, полноты и актуальности данных; обеспечение оперативного получения аналитической и управленческой отчетности; обеспечение возможности масштабирования системы за счет подключения новых модулей, сервисов и интеграций; создание технологической основы для дальнейшего развития цифровых сервисов Заказчика - - Значение характеристики не может изменяться участником закупки

Раздел «Реестр событий информационной безопасности» 2 - Контур реагирования на инциденты Раздел должен обеспечивать управление процессом реагирования на инциденты информационной безопасности. Данная функциональность предназначена для минимизации последствий утечек и обеспечения соблюдения регламентов реагирования. Функциональность должна включать: назначение ответственных за обработку инцидентов; управление статусами инцидентов (новый, в работе, закрыт и др.); контроль сроков реагирования; фиксацию действий по устранению инцидента; автоматическое уведомление участников процесса; контроль исполнения регламентов реагирования; эскалацию критических инцидентов; формирование отчетов по реагированию; поддержку маршрутов согласования решений. Мониторинг и отчетность Раздел должен обеспечивать мониторинг состояния информационной безопасности, уровня рисков утечки информации и ключевых показателей эффективности. Данная функциональность предназначена для предоставления актуальной информации руководству и ответственным подразделениям. Функциональность должна включать: формирование дашбордов по инцидентам ИБ; мониторинг уровня угроз и рисков утечки; контроль количества и динамики инцидентов; анализ эффективности мер защиты; выявление критических отклонений; контроль времени реагирования на инциденты; формирование регламентированной отчетности; выгрузку отчетов в Excel и PDF; формирование аналитических срезов по типам инцидентов, подразделениям, пользователям и периодам - - Значение характеристики не может изменяться участником закупки

Результаты внедрения модуля 2 - Дополнительно результатом внедрения системы должно стать формирование единого подхода к работе пользователей с цифровыми сервисами Заказчика, включая единые правила доступа, маршрутизации, уведомлений, журналирования действий, формирования документов и использования общих справочников. В результате внедрения системы должны быть обеспечены условия для последующей промышленной эксплуатации, сопровождения, развития функциональности и масштабирования системы в соответствии с потребностями Заказчика - - Значение характеристики не может изменяться участником закупки

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

Требования к структуре модулей системы - Общая архитектура. Архитектура системы должна обеспечивать функционирование единой цифровой среды, объединяющей функциональные модули, общие сервисы, механизмы хранения и обработки данных, средства управления доступом, инструменты журналирования, уведомления, отчетности и интеграционного взаимодействия. Архитектурные решения должны обеспечивать целостность системы, согласованность работы функциональных модулей, возможность централизованного администрирования, а также условия для последующего развития, адаптации и расширения функциональности без нарушения общей логики работы системы. Развитие функционала должно предусматривать единые подходы к организации пользовательского доступа, обработке данных, использованию общих справочников, хранению документов и истории изменений, а также к взаимодействию между модулями и внешними системами. Состав модулей и связи между ними. Структура системы должна предусматривать наличие функциональных модулей, автоматизирующих отдельные направления деятельности Заказчика, при сохранении их работы в рамках единого информационного контура. Состав модулей определяется требованиями настоящего Технического задания и может включать модули, предназначенные для автоматизации процессов пресс-службы, безопасности и гражданской обороны, учета персональных данных и согласий, административного управления, управления комплектацией и ремонта, а также иные модули, предусмотренные проектными решениями и этапами внедрения. Связи между модулями должны обеспечивать возможность обмена данными, использования единых справочников, передачи статусов, задач, документов, уведомлений и иных сущностей, необходимых для сквозного выполнения процессов и формирования консолидированной отчетности - - Значение характеристики не может изменяться участником закупки

Контур развертывания - Развертывание системы должно осуществляться на контуре Заказчика. Состав используемых сред, порядок развертывания, размещения компонентов системы, хранения данных, настройки серверной части, доступа пользователей и эксплуатации системы определяются с учетом ИТ-инфраструктуры Заказчика, требований информационной безопасности, эксплуатационных ограничений и проектных решений, принимаемых в рамках внедрения. При развертывании системы на контуре Заказчика должны быть обеспечены условия для функционирования пользовательской, серверной, интеграционной и сервисной составляющих системы. Общие сервисы. В структуре системы должны использоваться общие сервисы, обеспечивающие единые механизмы работы функциональных модулей и пользователей в рамках всей системы. К общим сервисам относятся, в частности, сервисы аутентификации и авторизации, ведения справочников, поиска, журналирования действий, хранения вложений и документов, формирования уведомлений, маршрутизации процессов, формирования отчетности, а также сервисы интеграционного взаимодействия. Использование общих сервисов должно обеспечивать единообразие пользовательских сценариев, повторное использование функциональных механизмов, снижение дублирования решений между модулями и упрощение сопровождения и развития Системы - - Значение характеристики не может изменяться участником закупки

Перечень разделов - В состав модуля управления деятельностью учреждения должны входить разделы, обеспечивающие автоматизацию основных направлений деятельности Заказчика в рамках единого информационного пространства. Перечень разделов модуля управления деятельностью учреждения определяется настоящим Техническим заданием и включает: раздел «Работа ПИДК»; раздел «Потребности ГКО»; раздел «База знаний»; раздел «Дашборд и средства навигации между модулями»; раздел «Пресс-служба»; раздел «Безопасность и гражданская оборона»; раздел «Управление информационных технологий»; раздел «Административное управление»; раздел «Управление закупок»; раздел «Управление комплектации и ремонта»; раздел «Реестр событий информационной безопасности»; раздел «Интеграция со смежными системами»; иные разделы, предусмотренные этапами внедрения, проектными решениями и потребностями Заказчика. Требования к подключению новых разделов. Функциональные разделы модуля управления деятельностью учреждения должны внедряться как составные части единой системы с обеспечением единых подходов к пользовательскому доступу, обработке данных, ведению справочников, журналированию действий, хранению документов, формированию отчетности и интеграционному взаимодействию. Каждый функциональный раздел должен обеспечивать выполнение предусмотренных для него задач, поддержку соответствующих пользовательских сценариев, возможность работы в рамках установленной ролевой модели и взаимодействие с иными разделами и модулями Системы в части передачи и получения данных, статусов, документов, уведомлений и иных сущностей - - Значение характеристики не может изменяться участником закупки

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

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

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

Требования к интерфейсу пользователя 2 - Адаптивность интерфейса. Интерфейс Системы должен обеспечивать корректное отображение и использование основных функциональных возможностей при работе с различных типов пользовательских устройств, включая персональные компьютеры, планшеты и мобильные устройства, в объеме, предусмотренном проектными решениями и требованиями Заказчика. Адаптивность интерфейса должна обеспечивать сохранение логики пользовательских сценариев, доступности основных элементов управления и читаемости отображаемой информации при изменении разрешения экрана, размеров рабочей области и типа используемого устройства. Единые UI?паттерны. Интерфейс Системы должен строиться с использованием единых UI-паттернов, обеспечивающих единообразное отображение элементов управления, карточек, справочников, форм ввода, уведомлений, фильтров, статусов, маршрутов согласования, отчетных блоков и иных компонентов пользовательского интерфейса. Использование единых UI-паттернов должно обеспечивать предсказуемость пользовательских действий, снижение времени на освоение системы, единый визуальный подход к работе в различных функциональных модулях, а также упрощение дальнейшего развития и сопровождения интерфейса Системы - - Значение характеристики не может изменяться участником закупки

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

Требования к ведению справочников и классификаторов 2 - Импорт и экспорт справочников. В Системе должна быть предусмотрена возможность импорта и экспорта справочников и классификаторов в объеме, необходимом для первичного заполнения, актуализации данных, переноса сведений и обеспечения интеграционного взаимодействия. Импорт и экспорт справочников должны обеспечивать загрузку и выгрузку данных в распространенных электронных форматах, используемых в деятельности Заказчика, с учетом требований к структуре данных, полноте реквизитов и контролю корректности загружаемой информации. Порядок импорта, экспорта, обновления и синхронизации справочников определяется проектными решениями, настройками системы и правилами ведения нормативно-справочной информации - - Значение характеристики не может изменяться участником закупки

Требования к поиску, фильтрации и сортировке данных - Полнотекстовый поиск. В Системе должна быть предусмотрена возможность полнотекстового поиска по данным, документам, карточкам, справочников и иным объектам, в отношении которых такая функциональность необходима для реализации пользовательских сценариев. Полнотекстовый поиск должен обеспечивать возможность поиска по наименованиям, реквизитам, текстовому содержанию документов, комментариям, описаниям и иным доступным пользователю данным в пределах его полномочий. Результаты поиска должны отображаться в удобной для пользователя форме с возможностью последующего перехода к найденным объектам, уточнения поискового запроса и применения дополнительных условий отбора. Контекстные фильтры по реквизитам. В Системе должна быть предусмотрена возможность применения контекстных фильтров по реквизитам объектов, документов, карточек, записей справочников, задач, поручений и иных сущностей системы. Фильтрация должна обеспечивать отбор данных по значениям атрибутов, статусам, датам, подразделениям, ответственным лицам, типам объектов, категориям, срокам и иным реквизитам, используемым в соответствующем функциональном модуле. Состав доступных фильтров должен определяться особенностями конкретного раздела системы, характером отображаемых данных и правами пользователя. Сохраненные представления. В Системе должна быть предусмотрена возможность сохранения пользовательских представлений данных, включая наборы фильтров, параметры сортировки, состав и порядок отображаемых колонок, а также иные настройки экранных форм и справочников, если это предусмотрено функциональностью соответствующего модуля. Сохраненные представления должны обеспечивать удобство повторного доступа пользователя к часто используемым вариантам отображения данных и повышать эффективность работы со справочниками, списками, журналами и отчетными представлениями. Порядок создания, изменения, использования и удаления сохраненных представлений определяется функциональными возможностями системы, настройками доступа пользователя - - Значение характеристики не может изменяться участником закупки

Требования к журналированию действий пользователей - Аудит?лог по ключевым сущностям. В Системе должно быть предусмотрено журналирование действий пользователей и системных событий по ключевым сущностям, используемым в функциональных модулях системы. К таким сущностям могут относиться документы, карточки объектов учета, поручения, задачи, записи реестров, справочники, учетные записи, согласования, статусы, маршруты, вложения, отчеты и иные объекты, изменение которых требует фиксации в целях контроля, прослеживаемости и последующего анализа. Аудит-лог должен обеспечивать фиксацию сведений о выполненном действии, объекте, пользователе, дате и времени операции, а также иных параметров, необходимых для понимания характера выполненного изменения. Неизменяемость и защищенность журнала. Журнал действий пользователей должен храниться в системе с обеспечением его целостности, защищенности и недопустимости несанкционированного изменения или удаления записей. Доступ к просмотру, выгрузке и администрированию журналов должен предоставляться ограниченному кругу пользователей в соответствии с установленными ролями и полномочиями. Механизмы хранения и защиты журналов должны обеспечивать возможность использования содержащихся в них сведений для внутреннего контроля, анализа событий, расследования инцидентов и подтверждения фактов выполнения операций в системе. Экспорт логов. В Системе должна быть предусмотрена возможность выгрузки данных журналов в объеме, необходимом для анализа, контроля, подготовки отчетности, проведения проверок и расследования инцидентов. Экспорт логов должен обеспечивать возможность отбора данных по периоду, пользователю, типу события, объекту системы и иным параметрам, необходимым для последующей обработки и анализа. Форматы выгрузки, состав экспортируемых данных и порядок предоставления доступа к логам определяются функциональными возможностями системы, требованиями Заказчика и установленными правилами безопасности - - Значение характеристики не может изменяться участником закупки

Требования к уведомлениям и маршрутизации задач - Типы уведомлений. В Системе должна быть предусмотрена возможность формирования и направления уведомлений пользователям в рамках выполнения функциональных процессов, задач, поручений, согласований, контроля сроков и иных событий системы. Уведомления могут использоваться для информирования пользователей о создании, изменении, назначении, согласовании, возврате, завершении, отклонении или наступлении контрольных сроков по объектам и процессам системы. В системе должны поддерживаться уведомления, формируемые по событиям, по изменению статусов, по контрольным срокам, по действиям пользователей и по иным основаниям, предусмотренным функциональными сценариями работы модулей. Эскалации и контроль сроков. Система должна обеспечивать контроль сроков исполнения задач, поручений, согласований, процессуальных действий и иных операций, для которых в системе устанавливаются плановые, контрольные или предельные сроки. При наступлении заданных условий система должна обеспечивать формирование уведомлений, напоминаний и эскалаций, направляемых исполнителям, ответственным лицам, руководителям или иным участникам процесса в соответствии с установленными правилами. Механизмы контроля сроков и эскалации должны обеспечивать повышение исполнительской дисциплины, своевременное выявление рисков нарушения сроков и поддержку принятия управленческих решений - - Значение характеристики не может изменяться участником закупки

Требования к уведомлениям и маршрутизации задач 2 - Настройка маршрутов согласования. В Системе должна быть предусмотрена возможность настройки маршрутов согласования документов, задач, поручений, заявок, приказов и иных объектов, для которых в рамках функциональных процессов требуется последовательное или параллельное прохождение согласующих этапов. Маршруты согласования должны учитывать тип объекта, категорию процесса, роль пользователя, принадлежность к подразделению, уровень ответственности и иные параметры, необходимые для корректной организации согласования. Система должна обеспечивать возможность изменения и адаптации маршрутов согласования в соответствии с требованиями Заказчика, а также фиксацию этапов согласования, принятых решений, комментариев, сроков и статусов прохождения маршрута - - Значение характеристики не может изменяться участником закупки

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

Требования к отчетности и выгрузке данных 2 - Экспорт данных В Системе должна быть предусмотрена возможность выгрузки данных, отчетов, справочников, карточек, журналов и иных информационных объектов в объеме, необходимом для последующей обработки, анализа, хранения, представления и использования в деятельности Заказчика. Экспорт данных должен обеспечиваться в распространенных электронных форматах, используемых в работе Заказчика, с учетом структуры выгружаемой информации, прав доступа пользователей и особенностей соответствующего функционального модуля. Порядок, состав и ограничения выгрузки данных определяются настройками системы, ролью пользователя и установленными правилами работы с информацией. API для отчетности При необходимости в Системе должна быть предусмотрена возможность предоставления данных для отчетности и аналитики посредством программных интерфейсов взаимодействия. Использование API может предусматриваться для передачи данных во внешние аналитические средства, смежные информационные системы, витрины данных и иные решения, используемые Заказчиком для формирования, консолидации и визуализации отчетной информации. Состав предоставляемых данных, формат взаимодействия, правила доступа и порядок использования API определяются проектными решениями, требованиями Заказчика и настройками интеграционного взаимодействия - - Значение характеристики не может изменяться участником закупки

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

Требования к информационной безопасности - Общие требования ИБ, модель угроз В Системе должны быть реализованы организационные и технические меры по защите информации в соответствии с законодательством Российской Федерации в области информации, информационных технологий, защиты информации и персональных данных. При формировании требований к защите информации должны учитываться положения Федерального закона № 149-ФЗ, согласно которому защита информации обеспечивается правовыми, организационными и техническими мерами, а также положения Федерального закона № 152-ФЗ в части обработки персональных данных. Для системы должна быть выполнена идентификация актуальных угроз безопасности информации, определены категории обрабатываемой информации, состав защищаемых ресурсов, нарушители, возможные сценарии реализации угроз и последствия нарушений конфиденциальности, целостности и доступности информации. На основании этого должна формироваться модель угроз и, при необходимости, иные организационно-распорядительные документы по защите информации. Для ИСПДн состав и содержание мер защиты должны определяться с учетом уровня защищенности персональных данных по Постановлению Правительства РФ № 1119 и приказу ФСТЭК России № 21. Если внедряемая Система либо ее отдельные подсистемы относятся к государственным информационным системам, иным информационным системам государственных органов, государственных унитарных предприятий или государственных учреждений, должны применяться новые требования ФСТЭК России, утвержденные приказом № 117 от 11.04.2025, вступившие в силу с 1 марта 2026 года. Эти требования заменили прежний режим по приказу ФСТЭК России № 17 для соответствующей категории систем - - Значение характеристики не может изменяться участником закупки

Требования к информационной безопасности 2 - При использовании шифровальных (криптографических) средств в составе системы либо при защите каналов связи и хранимой информации должны учитываться требования ФСБ России. Для ИСПДн с использованием СКЗИ действует приказ ФСБ России № 378 от 10.07.2014, а для государственных и иных систем государственных органов, ГУПов и госучреждений — приказ ФСБ России № 117 от 18.03.2025, вступивший в силу 6 апреля 2025 года. Регистрация событий безопасности В Системе должна быть обеспечена регистрация событий безопасности, достаточная для выявления попыток несанкционированного доступа, анализа инцидентов, контроля действий пользователей и администраторов, а также подтверждения фактов выполнения значимых операций в системе. Журналы безопасности должны формироваться по ключевым событиям аутентификации, изменению прав доступа, обращению к защищаемым данным, действиям администраторов, сбоям средств защиты, событиям интеграционного взаимодействия и иным событиям, значимым для безопасности. Записи журналов должны быть защищены от несанкционированного изменения и удаления, храниться в течение сроков, установленных внутренними регламентами Заказчика и проектными решениями, и быть доступны ограниченному кругу уполномоченных лиц. Для систем, подпадающих под регулирование ФСТЭК России, регистрация событий безопасности и контроль действий пользователей являются составной частью обязательных мер защиты информации; для ИСПДн и государственных систем это вытекает из приказов ФСТЭК № 21 и № 117. При использовании СКЗИ и иных специализированных средств защиты должна быть обеспечена регистрация событий, связанных с их эксплуатацией, отказами, изменением параметров и применением ключевой информации — в объеме, предусмотренном нормативными требованиями и эксплуатационной документацией. При необходимости должна быть предусмотрена возможность централизованного сбора и анализа журналов безопасности - - Значение характеристики не может изменяться участником закупки

Требования к защите от несанкционированного доступа - Идентификация и аутентификация В Системе должны быть реализованы механизмы идентификации и аутентификации пользователей, обеспечивающие допуск к системе только лиц, которым предоставлены соответствующие полномочия. Механизмы доступа должны обеспечивать однозначное сопоставление действий в системе с конкретной учетной записью пользователя, а также исключать возможность несанкционированного доступа к данным и функциям системы. При организации доступа должны учитываться корпоративные механизмы идентификации и аутентификации, используемые в ИТ-инфраструктуре Заказчика, включая подходы к централизованному управлению учетными записями. Для пользователей, администраторов и иных категорий лиц должны быть определены правила регистрации, предоставления, изменения, блокировки и прекращения доступа. Для ИСПДн и иных систем, подпадающих под регулирование ФСТЭК России, меры по идентификации и аутентификации должны определяться в составе организационных и технических мер защиты с учетом категории системы, модели угроз и уровня защищенности. Политики паролей, сеансов, многофакторной аутентификации В Системе должны быть предусмотрены политики управления аутентификационными данными и пользовательскими сеансами, обеспечивающие ограничение риска несанкционированного доступа. Такие политики должны охватывать требования к созданию, замене и хранению паролей, правила блокировки доступа при многократных ошибках ввода, управление длительностью пользовательских сеансов, завершение неактивных сеансов и иные параметры, необходимые для безопасной эксплуатации системы. Указанные меры должны устанавливаться в рамках общих требований к защите информации и предотвращению неправомерного доступа - - Значение характеристики не может изменяться участником закупки

Требования к защите от несанкционированного доступа 2 - При необходимости, с учетом категории пользователей, критичности функций, характера обрабатываемой информации и принятой модели угроз, в системе должна быть предусмотрена возможность применения многофакторной аутентификации. Решение о применении MFA, категориях пользователей, для которых она обязательна, и порядке ее использования должно приниматься на этапе проектирования системы и настройки мер защиты информации. Для привилегированных учетных записей и пользователей с доступом к чувствительным данным усиленные меры аутентификации рекомендуется предусматривать в обязательном порядке как часть комплекса организационных и технических мер защиты. Управление доступом к данным и функциям Система должна обеспечивать управление доступом к данным, документам, объектам учета, отчетности, административным функциям и иным возможностям системы на основе ролевой модели и принципа минимально необходимого объема полномочий. Пользователю должен предоставляться только тот доступ, который необходим для выполнения его служебных обязанностей и участия в предусмотренных бизнес-процессах. Защита информации по Федеральному закону № 149-ФЗ включает предотвращение неправомерного доступа, модифицирования, блокирования, копирования и иных неправомерных действий в отношении информации, что должно учитываться при проектировании механизмов авторизации. Управление доступом должно учитывать роль пользователя, принадлежность к подразделению, участие в конкретном процессе, статус исполнителя, согласующего, администратора или иного участника, а также иные атрибуты, необходимые для ограничения доступа к функциям и данным системы. Должны быть предусмотрены механизмы предоставления, изменения, временного делегирования, отзыва и прекращения прав доступа, а также фиксация таких действий в журнале безопасности. Для систем, в которых обрабатываются персональные данные или иная информация ограниченного доступа, состав мер по управлению доступом должен определяться с учетом применимых требований НПА - - Значение характеристики не может изменяться участником закупки

Требования к обработке персональных данных - Реестр ПДн В Системе должно быть предусмотрено ведение реестра персональных данных, обрабатываемых в рамках автоматизируемых процессов. Реестр должен обеспечивать фиксацию категорий субъектов персональных данных, состава обрабатываемых персональных данных, целей обработки, правовых оснований обработки, сроков хранения, действий с персональными данными, а также сведений о подразделениях и пользователях, имеющих доступ к соответствующим данным. Реестр ПДн должен использоваться как средство учета и контроля состава обрабатываемых сведений, а также как основа для последующей настройки прав доступа, аудита операций, определения необходимости получения согласий, применения мер защиты и реализации процедур блокирования, удаления либо обезличивания данных. Согласия субъектов и их версионность В Системе должна быть предусмотрена возможность регистрации, хранения и учета согласий субъектов персональных данных в случаях, когда обработка персональных данных осуществляется на основании согласия. В системе должна быть обеспечена возможность ведения версий согласий, фиксации даты их предоставления, срока действия, способа получения, статуса действия, а также хранения связанной подтверждающей информации. Версионность необходима для подтверждения правомерности обработки на конкретный момент времени и для отслеживания изменений условий согласия, включая изменение перечня данных, целей обработки и способов использования персональных данных. Отзыв согласий и обработка последствий В Системе должна быть предусмотрена возможность регистрации факта отзыва согласия субъектом персональных данных, даты и основания такого отзыва, а также запуска дальнейших действий по обработке его последствий. - - Значение характеристики не может изменяться участником закупки

Требования к обработке персональных данных 2 - После регистрации отзыва система должна обеспечивать возможность определения дальнейшего режима обработки данных: продолжение обработки при наличии законных оснований, ограничение отдельных операций, блокирование, удаление, уничтожение либо обезличивание персональных данных — в зависимости от правового основания, категории данных и требований внутренних регламентов Заказчика. Если применяется обезличивание, оно должно выполняться в соответствии с требованиями законодательства. Доступ к ПДн, аудит операций, выгрузки, обезличивание В Системе должен быть реализован ограниченный доступ к персональным данным в соответствии с ролями пользователей, их полномочиями, принадлежностью к подразделениям и участием в конкретных процессах. Доступ к просмотру, изменению, выгрузке, передаче, удалению и иным операциям с ПДн должен предоставляться только в объеме, необходимом для выполнения служебных обязанностей, с обязательной фиксацией действий в журнале аудита. В системе должна быть предусмотрена регистрация операций с персональными данными, включая просмотр, изменение, выгрузку, передачу, блокирование, обезличивание и удаление данных, с указанием пользователя, даты, времени, объекта операции и характера выполненного действия. Выгрузка ПДн должна осуществляться в контролируемом порядке и только при наличии соответствующих полномочий. При необходимости обезличивания должны применяться установленные законодательством подходы и такие методы, которые исключают сохранение доступа к информации ограниченного доступа в результатах обезличивания - - Значение характеристики не может изменяться участником закупки

Общие функциональные требования ко всем разделам - Справочники и карточки сущностей Во всех функциональных разделах модуля управления деятельностью учреждения Системы должна быть предусмотрена возможность ведения справочников и карточек сущностей, соответствующих предметной области конкретного раздела. Справочники должны обеспечивать хранение, просмотр, поиск, фильтрацию, сортировку и актуализацию записей, а карточки сущностей — хранение, отображение и изменение структурированных сведений об объектах учета, документах, задачах, событиях, операциях и иных сущностях, предусмотренных функциональностью раздела. Состав реквизитов справочников и карточек, правила их заполнения и порядок отображения определяются функциональным назначением соответствующего разделах модуля управления деятельностью учреждения и требованиями Заказчика. Статусы и жизненные циклы Для сущностей, используемых в функциональных разделах модуля управления деятельностью учреждения Системы, должны быть предусмотрены статусы и/или жизненные циклы, отражающие этапы их создания, обработки, согласования, исполнения, завершения, архивного хранения либо иного состояния. Изменение статусов должно осуществляться в соответствии с установленными правилами, маршрутами согласования, пользовательскими полномочиями или логикой соответствующего процесса. Система должна обеспечивать фиксацию текущего статуса сущности, историю его изменения, а также возможность использования статусов в механизмах поиска, фильтрации, контроля сроков, отчетности и интеграционного обмена - - Значение характеристики не может изменяться участником закупки

Общие функциональные требования ко всем разделам 2 - Вложения, версии документов Во всех разделах модуля управления деятельностью учреждения, где это требуется по функциональному назначению, должна быть предусмотрена возможность прикрепления вложений и работы с документами, связанными с объектами учета, задачами, поручениями, карточками, реестрами или иными сущностями. Система должна обеспечивать хранение вложенных файлов, их привязку к соответствующим сущностям, а также, при необходимости, ведение версий документов и истории изменений. Для документов и вложений должны быть предусмотрены механизмы контроля актуальности, доступа, замены, загрузки новых редакций и хранения связанной информации о пользователях, выполнивших соответствующие действия. Контроль сроков, уведомления, эскалации Во всех функциональных разделах модуля управления деятельностью учреждения Системы, где предусмотрены процессы с контрольными, плановыми, регламентными или предельными сроками, должна быть реализована возможность контроля таких сроков. Система должна обеспечивать автоматическое отслеживание наступления контрольных событий, формирование уведомлений пользователям, напоминаний о приближении сроков, а также эскалаций при риске нарушения либо факте нарушения установленных сроков в соответствии с принятыми регламентами Заказчика. Правила уведомлений, напоминаний и эскалаций определяются логикой соответствующего раздела модуля управления деятельностью учреждения , установленными маршрутами процессов и требованиями Заказчика - - Значение характеристики не может изменяться участником закупки

Общие функциональные требования ко всем разделам 3 - Отчетность и экспорт Во всех функциональных разделах модуля управления деятельностью учреждения Системы, которые предполагают за собой наличие «полезной» информации для Заказчика, должна быть предусмотрена возможность формирования отчетности по данным, объектам учета, статусам, срокам, результатам исполнения, действиям пользователей или иным сведениям, необходимым для решения задач соответствующего подразделения. Система должна обеспечивать формирование отчетных представлений, выгрузку справочников, карточек, журналов, аналитических выборок и иных данных в объеме, предусмотренном функциональностью конкретного раздела. Состав отчетности, форматы экспорта и объем доступных пользователю данных определяются назначением раздела модуля управления деятельностью учреждения, правами доступа и требованиями Заказчика. Аудит и история изменений Во всех функциональных разделах модуля управления деятельностью учреждения Системы должна быть предусмотрена фиксация действий пользователей и истории изменений по ключевым сущностям, объектам учета, документам, статусам, маршрутам, срокам и иным данным, изменение которых имеет значение для контроля и прослеживаемости процессов. Система должна обеспечивать хранение сведений о создании, изменении, удалении, согласовании, исполнении, передаче, назначении и иных действиях, совершаемых пользователями в рамках работы с данными и объектами системы. Состав фиксируемых событий, глубина хранения истории и доступ к журналам аудита определяются функциональным назначением раздела, требованиями информационной безопасности и правилами администрирования системы - - Значение характеристики не может изменяться участником закупки

Раздел «Интеграция со смежными системами» - Интеграция с АЗД Раздел должен обеспечивать двустороннюю интеграцию с системой автоматизации закупочной деятельности (АЗД) для обмена данными по закупкам, контрактам, этапам исполнения и финансовым резервам. Данная функциональность необходима для синхронизации финансовых и закупочных данных, контроля исполнения обязательств и предотвращения несоответствия данных между системами. Функциональность должна включать: получение данных по заявкам и закупкам из АЗД; получение данных по контрактам и этапам исполнения; получение данных о финансовых резервах и обязательствах; синхронизацию статусов закупок и финансовых резервов; протоколирование операций обмена; контроль ошибок при обмене; возможность повторной обработки данных при сбоях. Интеграция с СЭД «Практика» Раздел должен обеспечивать интеграционное взаимодействие с системой электронного документооборота «Практика» в части получения, передачи и актуализации данных, связанных с документами, резолюциями, поручениями, исполнителями и сроками исполнения. Данная функциональность необходима для синхронизации управленческих процессов между системой и действующим контуром электронного документооборота. Функциональность должна включать: получение документов из СЭД «Практика»; передачу документов в СЭД «Практика»; получение резолюций из СЭД «Практика»; передачу резолюций и связанных данных; синхронизацию карточек документов; синхронизацию карточек поручений; синхронизацию исполнителей; синхронизацию сроков исполнения; получение актуальных статусов документов; получение актуальных статусов поручений; отображение статуса документа на основе данных СЭД «Практика»; отображение статуса поручения на основе данных СЭД «Практика»; передачу результатов исполнения обратно в СЭД «Практика»; передачу подтверждающих материалов; фиксацию результатов обмена данными; контроль корректности интеграционного взаимодействия - - Значение характеристики не может изменяться участником закупки

Раздел «Работа ПИДК» - Статусы работы ИДК Раздел «Работа ПИДК» должен обеспечивать ведение и отображение статусов работы ПИДК в рамках единого информационного контура. Данная функциональность предназначена для оперативного контроля текущего состояния ПИДК, фиксации изменений в работе и предоставления пользователям актуальной информации о статусе объектов и связанных с ними процессов. Система должна обеспечивать возможность присвоения, изменения и отображения статусов работы ПИДК, а также использования этих статусов в механизмах поиска, фильтрации, контроля задач и формирования отчетности. Функциональность должна включать: ведение справочника статусов работы ПИДК; присвоение статуса объекту ПИДК; изменение текущего статуса ПИДК; отображение текущего статуса в карточке ПИДК; фиксацию истории изменения статусов; использование статусов при поиске и фильтрации; использование статусов в отчетности; контроль переходов между статусами; фиксацию даты и времени смены статуса; фиксацию пользователя, выполнившего изменение статуса. Задачи обслуживания ИДК Раздел должен обеспечивать постановку, сопровождение и контроль задач, связанных с обслуживанием ПИДК. Данная функциональность предназначена для организации работ по эксплуатации, техническому сопровождению и поддержанию ПИДК в работоспособном состоянии, а также для контроля сроков и результатов выполнения таких задач - - Значение характеристики не может изменяться участником закупки

Раздел «Работа ПИДК» 2 - Система должна обеспечивать регистрацию задач обслуживания, назначение исполнителей, фиксацию сроков, статусов и результатов выполнения, а также хранение связанной информации и подтверждающих материалов. Функциональность должна включать: создание задач обслуживания ПИДК; указание типа задачи; указание объекта ПИДК, к которому относится задача; описание содержания задачи; назначение исполнителя; назначение ответственного лица; указание планового срока выполнения; указание приоритета задачи; изменение статуса задачи; контроль сроков исполнения; формирование уведомлений по задачам; формирование напоминаний о приближении срока; формирование эскалаций при просрочке; фиксацию результатов выполнения задачи; прикрепление документов, комментариев и иных материалов; хранение истории выполнения задачи; отображение текущего состояния задач обслуживания. Отчетность по работе ИДК Раздел должен обеспечивать формирование отчетности по состоянию ПИДК, статусам работы, задачам обслуживания и результатам их выполнения. Данная функциональность предназначена для получения пользователями и руководством сводной информации о текущем состоянии объектов ПИДК, качестве и своевременности обслуживания, а также для последующего анализа и контроля. Система должна обеспечивать формирование отчетных и аналитических представлений на основании данных раздела с возможностью отбора информации по заданным параметрам. Функциональность должна включать: формирование отчетности по статусам работы ПИДК; формирование отчетности по задачам обслуживания; формирование отчетности по срокам исполнения задач; формирование отчетности по просроченным задачам; формирование отчетности по исполнителям; формирование отчетности по объектам ПИДК; формирование аналитических выборок за заданный период; использование фильтров при формировании отчетности; выгрузку отчетов в установленных форматах; представление отчетной информации в виде, удобном для последующего анализа - - Значение характеристики не может изменяться участником закупки

Раздел «Потребности ГКО» - Список потребностей ГКО Раздел «Потребности ГКО» должен обеспечивать ведение перечня потребностей ГКО в рамках единого информационного пространства. Данная функциональность предназначена для централизованного учета заявленных потребностей, упорядочивания работы с ними и предоставления пользователям актуальной информации о текущем состоянии исполнения. Система должна обеспечивать формирование и ведение списка потребностей с возможностью просмотра, поиска, фильтрации и использования сведений о потребностях в контрольных, исполнительских и отчетных сценариях. Функциональность должна включать: ведение списка потребностей ГКО; создание карточки потребности; отображение основных реквизитов потребности; указание инициатора потребности; указание ответственного лица; указание подразделения; указание описания потребности; указание даты создания; указание текущего статуса; поиск потребностей по основным реквизитам; фильтрацию потребностей по статусам; фильтрацию потребностей по ответственным лицам; фильтрацию потребностей по срокам; отображение истории изменений по потребности; использование списка потребностей при формировании отчетности. Создание потребности Раздел должен обеспечивать регистрацию новых потребностей ГКО и их последующее включение в общий контур учета и исполнения. Данная функциональность предназначена для формализации процесса инициирования потребности, фиксации ее параметров и обеспечения возможности дальнейшего контроля выполнения - - Значение характеристики не может изменяться участником закупки

Раздел «Потребности ГКО» 2 - Создание потребности должно осуществляться с заполнением обязательных реквизитов и последующей передачей потребности в работу в соответствии с установленной логикой разделя. Функциональность должна включать: создание новой потребности; заполнение карточки потребности; указание наименования потребности; указание описания потребности; указание инициатора; указание ответственного исполнителя; указание подразделения; указание приоритета; указание срока исполнения; прикрепление связанных документов и материалов; сохранение потребности в системе; присвоение начальному статусу; возможность редактирования потребности до передачи в исполнение; фиксацию даты и времени создания; фиксацию пользователя, создавшего потребность. Выполнение потребности Раздел должен обеспечивать сопровождение процесса выполнения потребности ГКО с фиксацией всех значимых действий, этапов и результатов исполнения. Данная функциональность предназначена для контроля исполнения заявленных потребностей и обеспечения прослеживаемости работы по каждой из них. Система должна обеспечивать назначение исполнителей, изменение статусов, фиксацию результатов выполнения и хранение подтверждающих материалов по завершении работ. Функциональность должна включать: передачу потребности в исполнение; назначение исполнителя; назначение соисполнителей при необходимости; изменение статусов в процессе выполнения; фиксацию этапов исполнения; добавление комментариев по ходу выполнения; прикрепление подтверждающих документов и материалов; фиксацию результата выполнения; завершение исполнения потребности; указание причины возврата или невозможности исполнения при необходимости; хранение истории действий по выполнению потребности; отображение текущего состояния исполнения в карточке потребности - - Значение характеристики не может изменяться участником закупки

Раздел «Потребности ГКО» 3 - Контроль статусов и сроков потребностей Раздел должен обеспечивать контроль статусов и сроков исполнения потребностей ГКО. Данная функциональность предназначена для своевременного выявления рисков просрочки, контроля текущего состояния потребностей и информирования ответственных лиц о необходимости выполнения действий. Система должна обеспечивать использование статусов и сроков как инструментов управления исполнением, контроля дисциплины и подготовки отчетной информации. Функциональность должна включать: контроль текущего статуса потребности; контроль сроков исполнения потребности; фиксацию плановой даты исполнения; фиксацию фактической даты исполнения; формирование уведомлений о приближении срока; формирование напоминаний ответственным лицам; формирование эскалаций при риске просрочки; формирование эскалаций при факте просрочки; использование статусов и сроков в поиске и фильтрации; использование статусов и сроков в отчетности; отображение просроченных потребностей; отображение потребностей, требующих внимания пользователя - - Значение характеристики не может изменяться участником закупки

Раздел «База знаний» - Список документов и инструкций Раздел «База знаний» должен обеспечивать централизованное ведение перечня документов, инструкций и иных информационных материалов, используемых в деятельности Заказчика. Данная функциональность предназначена для предоставления пользователям единой точки доступа к актуальным нормативным, методическим и справочным материалам, необходимым для выполнения служебных обязанностей. Система должна обеспечивать формирование структурированного списка документов и инструкций с возможностью поиска, просмотра, фильтрации и последующего использования материалов в рамках рабочих процессов. Функциональность должна включать: ведение списка документов и инструкций; создание карточки документа или инструкции; указание наименования документа; указание категории или типа документа; указание даты размещения; указание статуса актуальности; указание ответственного за материал; привязку документа к тематике, подразделению или направлению деятельности; поиск документов по наименованию и основным реквизитам; фильтрацию документов по категориям, статусам и иным признакам; просмотр карточки документа; переход к содержимому документа или вложенному файлу - - Значение характеристики не может изменяться участником закупки

Раздел «База знаний» 2 - Хранение и актуализация материалов Раздел должен обеспечивать хранение материалов базы знаний, их актуализацию и сопровождение в процессе эксплуатации системы. Данная функциональность предназначена для поддержания базы знаний в актуальном состоянии, контроля версий материалов и обеспечения пользователей достоверной информацией. Система должна обеспечивать хранение файлов, текстовых материалов и связанных данных, а также фиксацию изменений, выполняемых в отношении документов и инструкций. Функциональность должна включать: загрузку документов и инструкций в систему; хранение файлов и материалов; обновление ранее размещенных материалов; замену неактуальных версий документов; хранение истории изменений; ведение версий материалов; фиксацию даты актуализации; фиксацию пользователя, внесшего изменение; изменение статуса актуальности материала; архивирование устаревших материалов; контроль доступности пользователям только актуальных материалов в пределах заданной логики; прикрепление сопроводительных файлов и комментариев при необходимости. Опросы Раздел должен обеспечивать создание, проведение и сопровождение опросов пользователей по тематике, связанной с документами, инструкциями, внутренними регламентами и иными материалами базы знаний. Данная функциональность предназначена для сбора обратной связи, проверки ознакомления с материалами и получения сведений, необходимых для внутреннего контроля и анализа. Система должна обеспечивать подготовку опросов, определение состава участников, фиксацию ответов и хранение результатов прохождения. Функциональность должна включать: создание опросов; указание наименования опроса; формирование перечня вопросов; настройку вариантов ответов; определение целевой аудитории опроса; назначение сроков прохождения; публикацию опроса для пользователей; сбор ответов пользователей; фиксацию даты и времени прохождения; хранение результатов опроса; повторное проведение опроса при необходимости; использование результатов опросов в отчетности - - Значение характеристики не может изменяться участником закупки

Раздел «База знаний» 3 - Тестирование Раздел должен обеспечивать проведение тестирования пользователей по материалам базы знаний, внутренним инструкциям, регламентам и иным документам, размещенным в системе. Данная функциональность предназначена для проверки уровня ознакомления пользователей с материалами, контроля усвоения информации и подтверждения прохождения обязательных процедур. Система должна обеспечивать формирование тестов, назначение их пользователям или группам пользователей, фиксацию результатов прохождения и хранение истории тестирования. Функциональность должна включать: создание тестов; формирование набора вопросов для тестирования; настройку правильных ответов; определение правил прохождения теста; назначение тестирования пользователям; назначение тестирования группам пользователей; указание срока прохождения теста; фиксацию факта начала тестирования; фиксацию факта завершения тестирования; расчет результата прохождения; отображение результата пользователю; хранение истории прохождения тестов; повторное назначение тестирования при необходимости - - Значение характеристики не может изменяться участником закупки

Раздел «База знаний» 4 - Отчетность по прохождению опросов и тестирования Раздел должен обеспечивать формирование отчетности по прохождению опросов и тестирования пользователями. Данная функциональность предназначена для контроля исполнительской дисциплины, анализа результатов и предоставления руководству и ответственным лицам сведений о степени прохождения материалов и проверочных мероприятий. Система должна обеспечивать формирование отчетных и аналитических представлений на основании накопленных данных по опросам и тестам с возможностью отбора информации по пользователям, подразделениям, срокам и результатам. Функциональность должна включать: формирование отчетности по прохождению опросов; формирование отчетности по прохождению тестирования; отображение списка пользователей, прошедших опрос; отображение списка пользователей, не прошедших опрос; отображение списка пользователей, прошедших тестирование; отображение списка пользователей, не прошедших тестирование; формирование отчетности по срокам прохождения; формирование отчетности по результатам тестирования; формирование аналитики по подразделениям; формирование аналитики по группам пользователей; использование фильтров при подготовке отчетов; выгрузку отчетных данных в установленных форматах - - Значение характеристики не может изменяться участником закупки

Раздел «Дашборд и навигация между модулями» - Стартовая страница Раздел дашборда должен обеспечивать пользователю единый интерфейс для доступа к основным функциональным модулям системы и сводной информации. Данная функциональность предназначена для упрощения навигации, повышения оперативности доступа к ключевым данным и контроля состояния процессов в разных модулях. Функциональность должна включать: отображение сводной информации по состоянию ключевых показателей (KPI) и задач; визуализацию состояния процессов по модулям; доступ к отдельным функциональным блокам модулей по нажатию на соответствующие элементы интерфейса; возможность расширения и группировки блоков в раздел «В разработке» для модулей, находящихся в стадии внедрения; адаптивное отображение для разных устройств (ПК, планшет, мобильный телефон); предоставление краткой аналитической информации по каждому модулю на стартовой странице; поддержку интерактивного перехода к модулям с сохранением единой авторизации - - Значение характеристики не может изменяться участником закупки

Раздел «Дашборд и навигация между модулями» 2 - Модульные блоки Модульные блоки дашборда должны представлять собой визуальные элементы, отражающие доступные функциональные модули и их текущее состояние. Данная функциональность предназначена для быстрого выбора и перехода к интересующим модулям, а также для обеспечения наглядного контроля над рабочими процессами. Функциональность должна включать: отображение блоков по каждому модулю; выделение модулей, находящихся в стадии внедрения, с указанием статуса «В разработке»; возможность перехода к модулю из блока дашборда; группировку блоков по категориям или состоянию разработки; отображение уведомлений о критических событиях или сроках в рамках модуля; настройку порядка и размера блоков на странице; поддержку интерактивного расширения групп модулей; единый стиль отображения для всех модулей с сохранением единых UI-паттернов - - Значение характеристики не может изменяться участником закупки

Раздел «Пресс?служба» - Сбор и парсинг новостей Раздел пресс-службы должен обеспечивать автоматизированный мониторинг информационного поля по заданным источникам с последующим сбором и обработкой новостных публикаций. Функциональность данного подпункта предназначена для сокращения доли ручной работы сотрудников пресс-службы, повышения полноты мониторинга и обеспечения оперативного выявления значимых информационных сообщений. Система должна обеспечивать получение новостных публикаций из определенного перечня источников, извлечение значимых атрибутов публикации и сохранение результатов мониторинга для дальнейшей классификации, анализа и работы сотрудников пресс-службы. Функциональность должна включать: автоматический сбор новостей из заранее определенного перечня источников; получение данных с сайтов СМИ, официальных сайтов ведомств, официальных каналов, RSS-лент и иных источников, определенных Заказчиком; обработку новостных публикаций по заданной периодичности; парсинг заголовка публикации; парсинг текста публикации; парсинг даты и времени публикации; парсинг сведений об авторе публикации при наличии; парсинг сведений об источнике публикации; сохранение ссылки на первоисточник; исключение либо отметку дублирующихся публикаций при повторном обнаружении; сохранение результатов сбора в системе для последующего анализа и обработки - - Значение характеристики не может изменяться участником закупки

Раздел «Пресс?служба» 2 - Настройка источников мониторинга Раздел должен обеспечивать настройку и сопровождение источников, используемых для автоматического мониторинга новостей. Указанная функциональность необходима для гибкого управления перечнем отслеживаемых ресурсов и параметрами получения информации в зависимости от задач пресс-службы. Настройка источников мониторинга должна обеспечивать возможность изменения состава отслеживаемых ресурсов, определения периодичности опроса и задания параметров, влияющих на поиск, отбор и дальнейшую обработку публикаций. Функциональность должна включать: добавление новых источников мониторинга; изменение параметров ранее добавленных источников; отключение и повторное включение источников мониторинга; указание URL или иного идентификатора источника; настройку периодичности опроса источника; привязку источника к категориям мониторинга; указание ключевых слов и поисковых условий; настройку принадлежности источника к тематике, региону, организации или иному классификационному признаку; ведение перечня активных и неактивных источников; хранение параметров настройки по каждому источнику - - Значение характеристики не может изменяться участником закупки

Раздел «Пресс?служба» 3 - Классификация новостей Раздел должен обеспечивать классификацию новостных публикаций по признакам, необходимым для анализа информационного поля, последующей фильтрации данных и формирования отчетности. Классификация должна использоваться как для автоматизированной обработки публикаций, так и для поддержки аналитической работы сотрудников пресс-службы. Результаты классификации должны сохраняться в системе и использоваться при поиске, фильтрации, группировке публикаций и подготовке аналитических материалов. Функциональность должна включать: классификацию публикаций по темам; классификацию публикаций по регионам; классификацию публикаций по организациям; классификацию публикаций по уровню значимости; возможность автоматического присвоения классификационных признаков по заданным правилам; возможность ручной корректировки классификации пользователем; использование классификационных признаков в поиске, фильтрации, отчетности и аналитике; сохранение результатов классификации в карточке публикации - - Значение характеристики не может изменяться участником закупки

Раздел «Пресс?служба» 4 - Ручная загрузка новостей Раздел должен обеспечивать возможность ручного внесения новостных публикаций в систему в случаях, когда информация не была получена автоматически либо должна быть добавлена сотрудником пресс-службы отдельно. Такая функциональность необходима для обеспечения полноты учета и сохранения в системе всех значимых публикаций, подлежащих рассмотрению и анализу. Ручное добавление новостей должно осуществляться в рамках общей логики работы раздела с возможностью последующего редактирования, классификации, анализа и использования публикации в отчетности. Функциональность должна включать: создание карточки новости вручную; ввод заголовка публикации; ввод текста публикации; указание даты публикации; указание автора при наличии; указание источника публикации; добавление ссылки на первоисточник при наличии; присвоение тематических и иных классификационных признаков; прикрепление файлов и сопроводительных материалов при необходимости; сохранение вручную добавленных новостей в общем контуре мониторинга; возможность последующего редактирования вручную добавленной информации в рамках установленных прав доступа - - Значение характеристики не может изменяться участником закупки

Раздел «Пресс?служба» 5 - История мониторинга и действия пресс?службы по публикациям Раздел должен обеспечивать накопление и хранение истории работы с публикациями, начиная с момента их обнаружения или загрузки в систему и заканчивая обработкой сотрудниками пресс-службы. Указанная функциональность необходима для обеспечения прослеживаемости действий, анализа реакции на публикации и формирования полной картины работы по каждому информационному сообщению. История публикации должна отражать изменения ее состояния, действия пользователей, результаты анализа и иные сведения, связанные с рассмотрением и сопровождением публикации в системе. Функциональность должна включать: хранение истории поступления публикации в систему; фиксацию даты и времени обнаружения публикации; сохранение истории изменений карточки публикации; ведение истории классификации и переклассификации; фиксацию действий сотрудников пресс-службы по публикации; хранение отметок о рассмотрении публикации; хранение комментариев, решений, служебных пометок и иных сведений по публикации; возможность просмотра аналитики по публикации; сохранение истории связанных действий и событий в карточке публикации; использование истории публикации для последующего анализа и отчетности - - Значение характеристики не может изменяться участником закупки

Раздел «Пресс?служба» 6 - Экспорт отчетов Раздел должен обеспечивать формирование отчетности по результатам мониторинга и возможность выгрузки подготовленных материалов в распространенные форматы. Указанная функциональность предназначена для подготовки аналитических материалов, служебной отчетности и предоставления сведений руководству и заинтересованным подразделениям. Отчетность должна формироваться на основании данных, накопленных в системе, с учетом параметров поиска, фильтрации, классификации и аналитических признаков публикаций. Функциональность должна включать: формирование отчетов по собранным публикациям; формирование отчетов по источникам мониторинга; формирование отчетов по темам, регионам, организациям и уровням значимости; формирование отчетов по действиям пресс-службы; формирование аналитических выборок за заданный период; применение фильтров при формировании отчетов; выгрузку отчетов в формат Excel; выгрузку отчетов в формат PDF; возможность экспорта данных по результатам поиска и фильтрации; сохранение сформированных отчетов в системе при необходимости - - Значение характеристики не может изменяться участником закупки

Раздел «Безопасность и гражданская оборона» - Оповещение и экстренный обзвон сотрудников Раздел безопасности и гражданской обороны должен обеспечивать оперативное оповещение сотрудников при возникновении чрезвычайных, аварийных, эвакуационных и иных значимых событий. Данная функциональность предназначена для централизованной организации экстренного информирования работников и сокращения времени доведения информации до ответственных лиц и групп реагирования через мобильное приложение «АСУР». Система должна обеспечивать выполнение сценариев массового и адресного оповещения с использованием функциональных средств «АСУР» или иных каналов информирования, предусмотренных составом внедряемой функциональности. Функциональность должна включать: запуск оповещения по заранее определенным спискам получателей; формирование и использование перечней сотрудников для оповещения; фиксацию факта направления оповещения; фиксацию статуса доставки или результата оповещения в пределах технически доступных возможностей; сохранение истории проведенных оповещений; отображение информации о текущем и завершенном оповещении. Сценарии оповещения по типам событий Раздел должен обеспечивать формирование и использование сценариев оповещения в зависимости от типа события, характера угрозы, состава вовлеченных подразделений и категорий получателей. Указанная функциональность необходима для стандартизации действий при различных ситуациях и сокращения времени подготовки оповещения. Сценарии оповещения должны задавать состав получателей, порядок использования каналов связи, текстовое или голосовое содержание сообщений, а также правила дальнейшего информирования и эскалации - - Значение характеристики не может изменяться участником закупки

Раздел «Безопасность и гражданская оборона» 2 - Функциональность должна включать: создание сценариев оповещения по типам событий; настройку сценариев для событий, связанных с пожаром; настройку сценариев для событий, связанных с эвакуацией; настройку сценариев для событий, связанных с техногенными авариями; настройку сценариев для иных типов событий, определяемых Заказчиком; привязку сценария к составу получателей; привязку сценария к приоритетам оповещения; настройку каналов оповещения в рамках сценария; хранение параметров сценариев; возможность изменения и актуализации сценариев. Запуск обзвона Раздел должен обеспечивать запуск обзвона и оповещения как по инициативе пользователя, так и по заранее установленным условиям, правилам и событиям. Такая функциональность необходима для поддержки как оперативного реагирования, так и регламентных действий, выполняемых без ручного участия оператора. Запуск обзвона должен учитывать выбранный сценарий, состав получателей, приоритетность групп, используемые каналы оповещения и иные параметры, определенные в настройках системы. Функциональность должна включать: запуск обзвона в ручном режиме; запуск обзвона в автоматическом режиме; использование заранее настроенных регламентных триггеров; выбор сценария оповещения при запуске; выбор групп или отдельных получателей; фиксацию даты и времени запуска обзвона; отображение текущего состояния процесса оповещения; сохранение результатов выполнения обзвона; возможность остановки, повторного запуска или продолжения процедуры оповещения в рамках предусмотренной логики - - Значение характеристики не может изменяться участником закупки

Раздел «Безопасность и гражданская оборона» 3 - Голосовые шаблоны сообщений Раздел должен обеспечивать использование заранее подготовленных голосовых шаблонов сообщений для автоматизированного обзвона и информирования сотрудников. Указанная функциональность необходима для стандартизации содержания сообщений, сокращения времени на подготовку оповещения и обеспечения единообразного доведения информации до получателей. Голосовые шаблоны должны использоваться в рамках сценариев оповещения и быть доступны для выбора, привязки и изменения в соответствии с полномочиями пользователей. Функциональность должна включать: создание голосовых шаблонов сообщений; хранение голосовых шаблонов в системе; выбор голосового шаблона при настройке сценария; привязку шаблона к типу события; использование шаблона при запуске обзвона; изменение и актуализацию шаблонов; хранение нескольких вариантов шаблонов для разных сценариев; использование шаблонов для массового и адресного оповещения. Каскадный обзвон по приоритетным группам Раздел должен обеспечивать каскадный обзвон сотрудников с учетом заранее определенной очередности групп и приоритетов информирования. Такая функциональность необходима для соблюдения установленного порядка оповещения, в котором сначала информируются наиболее критичные категории получателей, а затем остальные участники процесса. Каскадный обзвон должен использоваться для организации поэтапного доведения информации до руководства, дежурных служб, ответственных лиц, сотрудников объектов и иных групп, определяемых Заказчиком. Функциональность должна включать: настройку приоритетных групп получателей; задание очередности обзвона групп; запуск обзвона по каскадной схеме; выделение групп руководства; выделение групп дежурных служб; выделение групп сотрудников объектов; переход к следующей группе в соответствии с настроенной логикой; фиксацию результатов оповещения по каждой группе; использование каскадного обзвона в рамках сценариев оповещения - - Значение характеристики не может изменяться участником закупки

Раздел «Безопасность и гражданская оборона» 4 - Альтернативные каналы Раздел должен обеспечивать использование альтернативных каналов информирования в случаях, когда основной способ оповещения недоступен, недостаточен либо требует дублирования сообщения. Указанная функциональность предназначена для повышения надежности системы оповещения и обеспечения доставки информации до получателей в различных условиях. Альтернативные каналы могут использоваться как резервный или дополнительный способ уведомления в составе единого сценария оповещения. Функциональность должна включать: использование резервных каналов информирования; использование нескольких каналов в рамках одного сценария; отправку сообщений по альтернативному каналу при недоступности основного; отправку уведомлений по SMS; отправку уведомлений по электронной почте; отправку push-уведомлений; фиксацию факта использования альтернативного канала; сохранение результатов доставки или попытки доставки в пределах технически доступных возможностей; настройку логики переключения между каналами оповещения - - Значение характеристики не может изменяться участником закупки

Раздел «Управление информационных технологий» - Раздел персональных данных и согласий Раздел Управления информационных технологий в части персональных данных должен обеспечивать централизованный учет сведений о субъектах персональных данных, основаниях их обработки, согласиях на обработку и передачу данных, а также связанных с этим действиях пользователей и системы. Данная функциональность предназначена для упорядочивания работы с персональными данными, обеспечения прослеживаемости операций и снижения рисков неконтролируемой обработки сведений. Раздел должен использоваться для ведения структурированных данных о составе обрабатываемых персональных данных, статусах согласий, сроках хранения, действиях с данными и основаниях обработки, а также для последующего контроля, аудита и исполнения процедур, связанных с отзывом согласия. Функциональность должна включать: ведение справочника субъектов персональных данных; ведение сведений о категориях субъектов персональных данных; ведение сведений о составе хранимых персональных данных; учет категорий персональных данных; учет правовых оснований обработки персональных данных; учет сроков хранения персональных данных; регистрацию согласий на обработку персональных данных; регистрацию согласий на передачу персональных данных; хранение согласий в системе; ведение версий согласий; отображение текущего статуса согласия; фиксацию статуса «действует»; фиксацию статуса «отозвано»; фиксацию статуса «истекло»; контроль операций с персональными данными; учет операций просмотра; учет операций изменения; учет операций выгрузки; учет операций удаления; учет операций обезличивания; ведение журнала аудита по персональным данным; фиксацию сведений о пользователе, выполнившем операцию; фиксацию даты и времени операции; фиксацию состава обработанных данных; фиксацию основания обработки - - Значение характеристики не может изменяться участником закупки

Раздел «Управление информационных технологий» 2 - Учет учетных записей и телефонный справочник Раздел должен обеспечивать ведение сведений об учетных записях пользователей и сопровождение корпоративного телефонного справочника. Данная функциональность предназначена для централизованного учета учетных записей, их статусов, связи с сотрудниками и подразделениями, а также для предоставления актуальной справочной информации, используемой в повседневной работе пользователей и в функциональных сценариях других разделах. Система должна обеспечивать ведение структурированных сведений об учетных записях, их жизненном цикле, принадлежности к сотрудникам и организационной структуре, а также поддержку поиска и использования контактных данных в справочном и прикладном режимах. Функциональность должна включать: ведение справочника учетных записей; регистрацию учетных записей; изменение учетных записей; блокировку учетных записей; архивирование учетных записей; привязку учетной записи к сотруднику; привязку учетной записи к подразделению; привязку учетной записи к роли; привязку учетной записи к полномочиям; фиксацию статуса учетной записи; отображение статуса «активна»; отображение статуса «временно заблокирована»; отображение статуса «деактивирована»; ведение корпоративного телефонного справочника; хранение ФИО; хранение должности; хранение подразделения; хранение контактных данных; поиск по сотруднику; поиск по подразделению; поиск по должности; поиск по номеру телефона; актуализацию сведений справочника; использование справочных данных в иных модулях Системы - - Значение характеристики не может изменяться участником закупки

Раздел «Управление информационных технологий» 3 - Автоматические действия при отзыве согласия Раздел должен обеспечивать автоматизированную обработку событий, связанных с отзывом согласия субъекта персональных данных, в пределах логики, допустимой действующими правилами обработки данных и внутренними регламентами Заказчика. Данная функциональность предназначена для сокращения ручных операций, повышения управляемости процессов прекращения обработки и обеспечения фиксации результатов выполненных действий. После регистрации отзыва согласия система должна обеспечивать запуск предусмотренных процедур в отношении соответствующих персональных данных, включая ограничение дальнейшей обработки, формирование задач, фиксацию статусов и выполнение последующих операций в зависимости от настроенной логики и оснований обработки. Функциональность должна включать: регистрацию события отзыва согласия; запуск процедуры обработки последствий отзыва; проверку наличия оснований для дальнейшей обработки данных; ограничение дальнейших операций с персональными данными при отсутствии оснований; запуск процедуры прекращения обработки персональных данных; инициирование удаления персональных данных в допустимых случаях; инициирование обезличивания персональных данных в допустимых случаях; формирование задач ответственным пользователям при необходимости ручной обработки; фиксацию даты запуска процедуры; фиксацию основания выполнения действий; фиксацию перечня обработанных данных; фиксацию результата выполнения процедуры; хранение подтверждения исполнения отзыва; отображение статуса исполнения действий по отзыву согласия; сохранение истории всех связанных операций в журнале аудита - - Значение характеристики не может изменяться участником закупки

Раздел «Административное управление» - Учет материальных ценностей Раздел административного управления должен обеспечивать централизованный учет материальных ценностей в рамках единого информационного пространства. Данная функциональность предназначена для систематизации сведений о материальных ценностях, контролю их состояния, местонахождения, ответственных лиц и истории движения. Система должна обеспечивать ведение карточек материальных ценностей, учет количественных и стоимостных характеристик, фиксацию статусов и сопровождение операций, связанных с жизненным циклом каждой единицы учета. Функциональность должна включать: ведение единого справочника материальных ценностей; формирование карточки материальной ценности; присвоение инвентарных номеров; присвоение учетных номеров; классификацию материальных ценностей по типам; учет количественных показателей; учет стоимостных показателей; учет состояния материальной ценности; учет местонахождения материальной ценности; учет закрепления за сотрудниками; учет закрепления за подразделениями; фиксацию ответственных лиц; хранение истории операций по каждой единице учета; формирование первичных учетных форм; формирование отчетов по движению материальных ценностей - - Значение характеристики не может изменяться участником закупки

Раздел «Административное управление» 2 - Выдача и передача материальных ценностей Раздел должен обеспечивать сопровождение процессов выдачи, возврата и передачи материальных ценностей между сотрудниками, подразделениями и материально ответственными лицами. Данная функциональность предназначена для контроля движения материальных ценностей, подтверждения оснований передачи и фиксации текущего держателя каждой единицы учета. Система должна обеспечивать оформление операций передачи, хранение сопроводительных документов и контроль сроков временной выдачи с возможностью формирования уведомлений и последующего анализа движения материальных ценностей. Функциональность должна включать: оформление заявок на выдачу материальных ценностей; поддержку маршрутов согласования заявок; регистрацию операций выдачи; регистрацию операций возврата; регистрацию операций передачи между подразделениями; регистрацию операций передачи между материально ответственными лицами; контроль оснований выдачи; контроль оснований передачи; учет заявки как основания выдачи; учет приказа как основания выдачи; учет акта как основания передачи; формирование актов приема-передачи; хранение актов приема-передачи; хранение сопроводительных документов; контроль сроков временной выдачи; формирование уведомлений о сроках возврата; отслеживание текущего держателя материальной ценности; отслеживание текущего статуса материальной ценности - - Значение характеристики не может изменяться участником закупки

Раздел «Административное управление» 3 - Инвентаризация Раздел должен обеспечивать планирование, проведение и фиксацию результатов инвентаризации материальных ценностей. Данная функциональность предназначена для проверки фактического наличия материальных ценностей, выявления расхождений с учетными данными и документирования итогов инвентаризационных мероприятий. Система должна обеспечивать формирование инвентаризационных ведомостей, учет результатов проверки, фиксацию излишков, недостач и иных расхождений, а также подготовку итоговых документов и аналитической отчетности. Функциональность должна включать: планирование плановых инвентаризаций; планирование внеплановых инвентаризаций; проведение инвентаризаций по подразделениям; проведение инвентаризаций по локациям; проведение инвентаризаций по материально ответственным лицам; формирование инвентаризационных ведомостей; фиксацию фактического наличия материальных ценностей; фиксацию состояния материальных ценностей; фиксацию расхождений с учетными данными; оформление результатов инвентаризации; учет излишков; учет недостач; учет пересортицы; оформление списания; оформление доначисления; поддержку фотофиксации; прикрепление подтверждающих документов; формирование итоговых актов; формирование аналитической отчетности по результатам инвентаризации - - Значение характеристики не может изменяться участником закупки

Раздел «Управление закупок» - Централизованная консолидация данных Раздел управления закупок должен обеспечивать централизованное получение, сведение и консолидацию финансовых данных из всех модулей и разделов Системы и смежных информационных систем. Данная функциональность предназначена для формирования единого контура закупочного учета, сопоставимости показателей между управлениями и прозрачности финансовых потоков. Функциональность должна включать: сбор финансовых данных из модулей и разделов; сведение данных в единую структуру для сопоставимости; консолидацию плановых данных; консолидацию фактических данных; анализ данных по управлению, объекту, статье, периоду и источнику финансирования; формирование сводного финансового баланса по организации. Учет бюджетных обязательств и лимитов Раздел должен обеспечивать ведение лимитов бюджетных обязательств (ЛБО) и контроль их использования в рамках финансового планирования. Данная функциональность предназначена для предотвращения превышения бюджетных лимитов, контроля кассового плана и соблюдения бюджетной дисциплины - - Значение характеристики не может изменяться участником закупки

Раздел «Управление закупок» 2 - Функциональность должна включать: ведение лимитов бюджетных обязательств по периодам и направлениям; резервирование лимитов при инициации закупки; корректировку лимитов по факту исполнения; автоматическую проверку доступности лимитов при создании финансовых операций; блокировку или перевод на согласование операций при превышении лимита; контроль кассового плана в режиме план/факт. Планирование и план?графики Раздел должен обеспечивать формирование и ведение финансовых планов и план-графиков закупок, а также контроль изменений и отклонений. Данная функциональность предназначена для соблюдения бюджетной дисциплины и согласованного распределения ресурсов. Функциональность должна включать: формирование финансовых планов; формирование план-графиков закупок; учет изменений план-графиков с сохранением истории версий; сверку план-графика с бюджетными параметрами; контроль отклонений от плана; фиксацию причин изменений; хранение истории изменений планов - - Значение характеристики не может изменяться участником закупки

Раздел «Управление закупок» 3 - Контроль и согласование Раздел должен обеспечивать контроль соблюдения правил бюджетной дисциплины, согласование финансовых операций и корректировок бюджета. Данная функциональность необходима для снижения рисков превышения лимитов, несоответствия статьям бюджета и нарушения сроков исполнения. Функциональность должна включать: настройку маршрутов согласования финансовых документов; настройку маршрутов согласования корректировок бюджета; контроль соблюдения бюджетной дисциплины; применение контрольных правил; уведомления ответственных лиц при критических отклонениях; уведомления при риске кассового разрыва; уведомления при нарушении сроков исполнения. Аналитика и отчетность Раздел должен обеспечивать контроль соблюдения правил бюджетной дисциплины, согласование финансовых операций и корректировок бюджета. Данная функциональность необходима для снижения рисков превышения лимитов, несоответствия статьям бюджета и нарушения сроков исполнения. Функциональность должна включать: настройку маршрутов согласования финансовых документов; настройку маршрутов согласования корректировок бюджета; контроль соблюдения бюджетной дисциплины; применение контрольных правил (превышение лимита, несоответствие статьям, дублирование обязательств); уведомления ответственных лиц при критических отклонениях; уведомления при риске кассового разрыва; уведомления при нарушении сроков исполнения - - Значение характеристики не может изменяться участником закупки

Раздел «Управление комплектации и ремонта» - Контроль исполнения задач Раздел управления комплектации и ремонта должен обеспечивать регистрацию, сопровождение и контроль выполнения задач, связанных с работами по обеспечению объектов оборудованием, комплектующими и проведением ремонтных мероприятий. Данная функциональность предназначена для повышения прозрачности процессов, контроля сроков и качества выполнения задач. Функциональность должна включать: создание и ведение задач (тип задачи, объект/локация, описание, приоритет, сроки, ответственные); назначение исполнителей и возможность переназначения с фиксацией причины; формирование исполнительской отчетности по задаче (фотофиксация, прикрепление документов, комментарии); контроль сроков исполнения: план/факт, просрочка, критичность отклонений; автоматические уведомления о ключевых сроках, возвратах и просрочках; эскалация руководителю при нарушении сроков; ведение журнала действий и истории изменений по задаче (аудит); формирование дашбордов и отчетов по дисциплине исполнения, просрочкам, нагрузке по подразделениям и исполнителям; интеграция с АЗД для привязки задач к заявкам/закупкам и получения/передачи статусов. Проверка заявок Раздел должен обеспечивать автоматическую проверку заявок на комплектацию и ремонт. Данная функциональность предназначена для повышения точности проверки, сокращения ошибок и ускорения обработки заявок - - Значение характеристики не может изменяться участником закупки

Раздел «Управление комплектации и ремонта» 2 - Функциональность должна включать: автоматическую проверку полноты комплекта документов (обоснование, КП, ТЗ, расчет НМЦК, план-график); проверку обоснования закупки; сопоставление данных ТЗ и КП (наименование закупки, характеристики, единицы измерения, объемы); контроль срока актуальности КП (не старше установленного периода); проверку реквизитов КП (подпись, дата, ответственное лицо); проверку контрагентов (существование, корректность данных, соответствие по ОКВЭД, проверка по РНП); выявление признаков аффилированности по заданным правилам; проверку бюджетно-классификационных параметров (ЦСР, ВР, КОСГУ, ОКПД-2, сумма, наименование); проверку корректности расчета НМЦК (логические/арифметические несоответствия); сверку заявки с планом-графиком по ключевым реквизитам; формирование результата проверки: список замечаний, уровень критичности, рекомендации по исправлению, решение (допустить/вернуть). Проверка смет Раздел должен обеспечивать автоматизированную проверку сметной документации. Данная функциональность предназначена для выявления типовых ошибок, проверки полноты и корректности структуры смет, а также формирования аналитической информации о качестве смет. Функциональность должна включать: загрузку сметной документации; проверку структуры сметы и полноты обязательных разделов; выявление типовых ошибок и несоответствий; классификацию замечаний по критичности: критичные, существенные, рекомендательные; формирование протокола проверки (ошибка, обоснование, ссылка на раздел/позицию, рекомендация к исправлению); поддержку процесса проверки филиал ? центральный аппарат с возвратом на доработку и повторной проверкой; хранение истории версий смет; хранение истории замечаний и исправлений; формирование аналитической отчетности по качеству смет и повторяемости ошибок - - Значение характеристики не может изменяться участником закупки

Раздел «Реестр событий информационной безопасности» - Реестр событий информационной безопасности Раздел должен обеспечивать ведение единого реестра событий информационной безопасности, связанных с потенциальными и фактическими утечками информации. Данная функциональность предназначена для централизованного учета инцидентов, их анализа и обеспечения прозрачности процессов реагирования. Функциональность должна включать: создание и ведение карточек событий ИБ; указание типа инцидента (утечка, попытка утечки, нарушение политики доступа и др.); указание источника события (пользователь, система, внешнее подключение); фиксацию времени и даты события; указание затронутых информационных ресурсов; классификацию уровня критичности инцидента; назначение ответственных за обработку инцидента; хранение истории изменений и статусов инцидента; возможность фильтрации и поиска событий по ключевым параметрам. Паспорт инцидента информационной безопасности Раздел должен обеспечивать формирование и хранение паспорта инцидента информационной безопасности в структурированном виде. Данная функциональность позволяет централизованно хранить всю информацию по инциденту и контролировать полноту и актуальность данных. Функциональность должна включать: структурированное хранение данных по инциденту; фиксацию описания инцидента; хранение доказательной базы (логи, файлы, скриншоты); хранение результатов расследования; фиксацию принятых мер реагирования; хранение сопутствующих документов; ведение версий паспорта инцидента; контроль актуальности информации; возможность интеграции с системами сбора логов - - Значение характеристики не может изменяться участником закупки

Результаты внедрения модуля - По результатам внедрения модуля Заказчик должен получить единый информационный контур для автоматизации и сопровождения деятельности структурных подразделений, обеспечивающий централизованный доступ к данным, документам, задачам, отчетности и иным объектам учета в рамках установленных полномочий пользователей. Результатами внедрения системы являются: автоматизация ключевых процессов структурных подразделений Заказчика в рамках предусмотренных функциональных модулей; создание единой точки входа пользователей в систему с разграничением прав доступа по ролям и полномочиям; сокращение доли ручных операций при обработке документов, поручений, заявок, справочников, карточек объектов и иных сущностей; повышение прозрачности бизнес-процессов, статусов исполнения, сроков и результатов деятельности подразделений; обеспечение контроля исполнительской дисциплины, сроков исполнения задач, поручений, согласований и процессуальных действий; обеспечение централизованного хранения данных, документов, вложений, версий и истории изменений; повышение достоверности, актуальности и полноты информации, используемой в работе подразделений; обеспечение возможности оперативного поиска, фильтрации, анализа и выгрузки данных; формирование регламентной, аналитической и управленческой отчетности по направлениям деятельности; обеспечение интеграционного взаимодействия с внешними и смежными информационными системами в пределах предусмотренного объема работ; создание условий для дальнейшего развития системы, подключения новых модулей, сервисов и пользовательских сценариев; повышение качества управленческих решений за счет консолидации информации и доступа к актуальным данным в единой системе - - Значение характеристики не может изменяться участником закупки

Преимущества, требования к участникам

Преимущества: Не установлены

Требования к участникам: 1. Требования к участникам закупок в соответствии с ч. 2.1 ст. 31 Закона № 44-ФЗ 1.1? Требования в соответствии c пунктом 4 ПП РФ от 29.12.2021 №2571 Дополнительные требования Наличие у участника закупки опыта исполнения (с учетом правопреемства) в течение трех лет до даты подачи заявки на участие в закупке контракта или договора, заключенного в соответствии с Федеральным законом от 18 июля 2011 года № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» при условии исполнения таким участником закупки требований об уплате неустоек (штрафов, пеней), предъявленных при исполнении таких контракта, договора. Стоимость исполненных обязательств по таким контракту, договору должна составлять не менее двадцати процентов начальной (максимальной) цены контракта. Информация и документы, подтверждающие соответствие участника закупки дополнительному требованию, установленному в соответствии с частью 2.1 ст. 31 Закона о контрактной системе, являются информация и документы, предусмотренные хотя бы одним из следующих подпунктов: а) номер реестровой записи в предусмотренном Законом о контрактной системе реестре контрактов, заключенных заказчиками (в случае исполнения участником закупки контракта, информация и документы в отношении которого включены в установленном порядке в такой реестр и размещены на официальном сайте единой информационной системы в информационно-телекоммуникационной сети "Интернет"); б) выписка из предусмотренного Законом о контрактной системе реестра контрактов, содержащего сведения, составляющие государственную тайну (в случае исполнения участником закупки контракта, информация о котором включена в установленном порядке в такой реестр); в) исполненный контракт, заключенный в соответствии с Законом о контрактной системе, или договор, заключенный в соответствии с Федеральным законом "О закупках товаров, работ, услуг отдельными видами юридических лиц", а также акт приемки поставленных товаров, выполненных работ, оказанных услуг, подтверждающий цену поставленных товаров, выполненных работ, оказанных услуг. 2. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 3. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ: Основанием для установки указания запретов, ограничений закупок товаров, происходящих из иностранных государств, выполняемых работ, оказываемых услуг иностранными лицами, а так же преимуществ в отношении товаров российского происхождения, а также товаров происходящих из стран ЕАЭС, выполняемых работ, оказываемых услуг российскими лицами, а также лицами, зарегистрированными в странах ЕАЭС, является Постановление Правительства Российской Федерации о мерах по предоставлению национального режима от 23.12.2024 № 1875.

Обеспечение заявки

Требуется обеспечение заявки: Да

Размер обеспечения заявки: 970 000,00 РОССИЙСКИЙ РУБЛЬ

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Обеспечение заявки на участие в закупке предоставляется одним из следующих способов: 1) путем блокирования денежных средств на банковском счете, открытом таким участником в банке, включенном в перечень, утвержденный Правительством Российской Федерации (далее - специальный счет), для их перевода в случаях, предусмотренных статьей 44 Федерального закона № 44-ФЗ, на счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими заказчику, или в соответствующий бюджет бюджетной системы Российской Федерации. Требования к таким банкам, к договору специального счета, к порядку использования имеющегося у участника закупки банковского счета в качестве специального счета устанавливаются Правительством Российской Федерации. 2) путем предоставления независимой гарантии, соответствующей требованиям статьи 45 Федерального закона № 44-ФЗ. Участник закупки для подачи заявки на участие в закупке выбирает с использованием электронной площадки способ обеспечения такой заявки путем указания реквизитов специального счета или указания номера реестровой записи из реестра независимых гарантий, размещенного в единой информационной системе.

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03100643000000017300, л/c 04731D10040, БИК 004525988, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/c 40102810545370000003

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации): Получатель Номер единого казначейского счета Номер казначейского счета БИК ТОФК УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО Г. МОСКВЕ (ФГКУ РОСГРАНСТРОЙ) ИНН: 7709827266 КПП: 770801001 КБК: 10311610051019000140 ОКТМО: 45378000 40102810545370000003 03100643000000017300 004525988

Условия контракта

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, г Москва, вн.тер.г. муниципальный округ Красносельский, ул Садовая-Спасская, д. 18 стр. 1

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Обеспечение исполнения контракта

Требуется обеспечение исполнения контракта: Да

Размер обеспечения исполнения контракта: 29 100 000,00 ? (30 %)

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Не позднее пяти рабочих дней, следующих за днем размещения заказчиком в соответствии с частью 2 статьи 51 Федерального закона № 44-ФЗ проекта контракта, участник закупки с которым заключается контракт подписывает усиленной электронной подписью лица, имеющего право действовать от имени участника закупки, проект контракта и одновременно размещает на электронной площадке подписанный проект контракта, а также документ, подтверждающий предоставление обеспечения исполнения контракта в соответствии с Федеральным законом № 44-ФЗ.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03100643000000017300, л/c 04731D10040, БИК 004525988, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/c 40102810545370000003

Требования к гарантии качества товара, работы, услуги

Требуется гарантия качества товара, работы, услуги: Да

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Гарантийный срок на результаты оказанных услуг устанавливается не менее 12 (Двенадцати) месяцев и исчисляется с даты подписания Сторонами Документа о приемке услуг в ЕИС по последнему этапу исполнения Контракта

Информация о требованиях к гарантийному обслуживанию товара:

Требования к гарантии производителя товара:

Обеспечение гарантийных обязательств

Требуется обеспечение гарантийных обязательств: Да

Размер обеспечения гарантийных обязательств: 4 850 000,00 Российский рубль

Порядок предоставления обеспечения гарантийных обязательств, требования к обеспечению: В соответствии с проектом контракта

Платежные реквизиты для обеспечения гарантийных обязательств: p/c 03100643000000017300, л/c 04731D10040, БИК 004525988, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/с 40102810545370000003

Информация о банковском и (или) казначейском сопровождении контракта

Банковское или казначейское сопровождение контракта не требуется

Документы

Общая информация

Документы

Журнал событий