Подготовка технического задания на систему для СМЭВ: основные шаги и развилки

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

Развилки на пути создания информационной системы

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

• планируется развитие (модернизация) системы или разработка ИС «с нуля»?
• планируется ли использовать базовое ПО при разработке системы?
• должна ли система удовлетворять тенденциям импортозамещения?
• требуется ли системе пользовательский интерфейс?
• какие пользователи будут работать в системе, требуется ли разграничение прав доступа?
• система создается для межведомственного взаимодействия, оказания государственных услуг, или для решения обеих задач?
• какие данные будут храниться в системе?
• должна ли система обмениваться данными с другими ведомственными информационными системами?
• требуется ли в системе функционал формирования отчетов?
• какие процессы необхоодимо автоматизировать в системе, что она должна уметь делать без вмешательства пользователя?

Ответы на эти вопросы необходимо обязательно отразить в техническом задачи или передать разработчикам, подготавливающим постановку на систему.

Разберем перечисленные особенности более подробно.

Модернизация или разработка новой системы

Достаточно часто у ведомств уже есть СМЭВ-система. И даже если она не работает, морально устарела, а разработчик ни в какую не хочет ее развивать – все равно очень желательно указывать в названии работ формулировку «модернизация». В противном случае у Минкомсвязи возникнет закономерный вопрос: «Зачем ведомству столько однотипных информационных систем?».

Если одна информационная система уже есть, а оформлять работы как модернизацию не хочется – можно воспользоваться одним из двух вариантов:

• вывести старую ИС из эксплуатации – процесс сложный, требующий выполнения ряда формальных условий (например, с момента создания ИС должно пройти 5 лет);
• указать в названии работ специфику задач, которые будет выполнять новая система (например, «создание ИС в целях обеспечения межведомственного взаимодействия департамента делопроизводства» или «создание ИС с целью оказания государственной услуги «Выдача охотничьего билета» в электронном виде».

Однако, как правило, подобные ухищрения не требуются. Минкомсвязи и проверяющие организации не будут против, если под видом модернизации будет осуществлено полное обновление системы, включая замену подрядчика, базового ПО, набора госуслуг и подключенных видов сведений.

Единственный очевидный минус «модернизации» существующей ИС вместо создания новой – необходимость подробного описания в ТЗ «объекта автоматизации». В данном разделе, как правило, указывается история создания системы, структура её компонентов, функциональные возможности, ранее переведенные в электронный вид госуслуги, подключенные сервисы СМЭВ. Всю эту информацию можно найти в ТЗ на создание/развитие старой системы. Если же система создается «с нуля», в разделе «Объект автоматизации» достаточно указать «Объектом автоматизации выступает деятельность ведомства по оказанию государственных услуг и осуществлению межведомственного взаимодействия в электронном виде».

Наличие базового ПО

Базовое ПО – программное обеспечение, на основании которого создается система. Например, в роли базового ПО может выступать система документооборота или ERP-решение.

Как правило, базовое ПО всегда используется разработчиками при создании СМЭВ-системы. Вместо того чтобы каждый раз разрабатывать решение с нуля они берут за основу готовое ядро или даже полноценную систему и кастомизируют его под требования ведомства-заказчика.

Если при создании системы планируется использовать базовое ПО – в ТЗ обязательно должно содержаться указание на способ его приобретения. Либо ведомство-заказчик закупает ПО самостоятельно или в рамка контракта на создание ИС, либо его закупает исполнитель и передает заказчику все необходимые права и лицензии.

С осторожностью стоит относиться к использованию в качестве базового ПО так называемого «открытого программного обеспечения». Дело в том, что даже если ПО может свободно распространяться и перерабатываться – у него все равно есть лицензия (как правило, GNU). В лицензии может быть указано, что любой продукт, написанный на базе данного свободного ПО также должен распространяться свободно. Такая ситуация недопустима.

Импортозамещение

В случае организации закупки под конкретного поставщика (разработчика) в ТЗ часто включают технические требования к ПО: операционную систему, базу данных, базовое ПО, языки программирования и т.д. В данном случае важно не переусердствовать, так как некоторые требования могут напрямую противоречить политике импортозамещения.

В качестве операционной системы рекомендуется указывать «Astra Linux» или «ROSA Linux», в качестве БД «PostgresSQL». Пусть даже фактически решение будет работать не на Astra, а, например, на CentOS. Все равно, разработчик обеспечит совместимость решения с «правильной» ОС, а ведомство обезопасит себя от лишнего внимания проверяющих организаций.

Что касается базового ПО —  желательно включить в ТЗ требование о том, что разработчик должен подтвердить лицензионную используемого чистоту Базового ПО и факт его наличия в «Едином реестре российских программ для электронных вычислительных машин и баз данных» (он же – «реестр отечественного ПО»).

Пользовательский интерфейс

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

Если интерфейс в системе не нужен, в ТЗ обязательно должно содержаться подробное описание способа интеграции существующей ведомственной ИС с создаваемой СМЭВ-системой, в том числе:

• на чьей стороне реализуется API;
• тип сервиса;
• типы и содержание сообщений (передаваемых данных);
• требования к логированию действий СМЭВ-системы и т.д.

Если интерфейс нужен, в ТЗ включаются разделы:

• брендбук и требования к стандартизации интерфейсов (описание и примеры стилей, шрифтов, иконок и визуальных решений);
• требования к эргономике и эстетике (общие требования к интерфейсам);
• требования к лингвистическому обеспечению (требования к используемым языкам).

Пользователи

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

Обратная ситуация – решение, в котором работает множество пользователей, различающихся:

• функциональными обязанностями и задачами;
• структурными подразделениями;
• местом осуществления трудовой деятельности (территориальные органы, представительства);
• типами используемых устройств (ПК, ноутбуки, планшеты) и операционных систем (Windows, Linux, iOS).

Для такой системы в ТЗ обаятельно обязательно необходимо описать следующие особенности:

• использование адаптивного web-интерфейса (отсутствие необходимости установки ПО на локальное устройство, доступ к решению через web-браузер);
• функционал и логику работы системы авторизации;
• функционал системы администрирования (создание и редактирование учетных записей пользователей, объединение пользователей в группы, журнал сессий, журнал действий пользователей в системе);
• функционал личного кабинета пользователя (редактирование информации о себе, контактных данных, настройка интерфейсов);
• функционал распределения прав доступа (права на чтение/ редактирование/ создание записей по каждой услуге, межведомственному запросу и т.д.).

Госулуги

Если система участвует в процессах оказания государственных услуг в электронном виде, в ТЗ должна содержаться следующая информация:

• перечень услуг и степень (этап) автоматизации;
• необходимость функционала обработки в системе заявлений, поступивших в бумажном виде;
• особенности и бизнес-логика (алгоритм) обработки оператором поступивших заявлений (как формируются ответы заявителю, какие этапы проходит заявление, подразумевается ли передача крупных файлов, требуется ли функционал записи на прием и т.д.);
• указание на необходимость разработки и тестирования исполнителем видов сведений СМЭВ3 для обеспечения приема заявлений с ЕПГУ через СМЭВ;
• указание на необходимость разработки исполнителем частных технических заданий на создание интерактивных форм заявлений на ЕПГУ.

Создание и настройка процесса обработки заявлений на предоставление госуслуг в электронном виде – одна из сложнейших задач для разработчика. Очень желательно максимально подробно изложить этот пункт в ТЗ.

Межведомственное взаимодействие

Межведомственное взаимодействие может быть организовано в двух направлениях:

1. оператор направляет из системы запрос к ФОИВ-поставщику данных и получает ответ;
2. ФОИВ-потребитель данных направляет в систему запрос, а оператор (или система) готовит ответ и направляет его потребителю.

В первом случае все достаточно просто. В ТЗ необходимо указать перечень подключаемых видов сведений ФОИВ-поставщиков и дополнительный функционал обработки ответов (возможность прикрепления к заявлению/делу, возможность выгрузки в PDF и т.д.). Единственный нюанс – для направления запроса к некоторым видам сведений требуется его подписания не только СМЭВ-подписью системы, но и подписью (ЭП) конкретного сотрудника (например, виды сведений «Сведения о доходах физических лиц по справкам 2-НДФЛ», «Прием обращений в ФГИС ЕГРН» и др.). Если такие ВС требуются ведомству, в ТЗ необходимо включить фразу «Стандартный web-интерфейс системы должен поддерживать функционал подписи СМЭВ-запросов ЭП ответственного сотрудника».

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

• перечень видов сведений, ссылки на ТКМВ;
• необходимость разработки и тестирования исполнителем видов сведений для их вывода в продуктивную среду СМЭВ3;
• бизнес-логику обработки поступающих запросов (будет ли оператор отвечать на запросы вручную, или они должны обрабатываться и отправляться системой в автоматическом режиме).

Хранение данных

Обычно помимо информации, относящейся непосредственно к межведомственному взаимодействию в СМЭВ-системах хранятся сопутствующие данные:

• сведения о физических лицах и организациях, подававших заявления на оказания государственных услуг;
• данные, необходимые для обработки входящих СМЭВ-запросов;
• нормативно-справочная информация и др.

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

Для удобства обработки (создание, хранение и редактирование) этой информации в системе могут создаваться отдельные реестры. Если связать эти реестры между собой открываются широкие возможности сортировки и анализа данных. Например, можно посмотреть, какие заявления на предоставления госуслуг заявитель уже подавал ранее, в отношении какого объекта чаще всего запрашивается информация из других ведомств и т.д.

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

Интеграции, обмен данными с другими системами

СМЭВ-системы обычно интегрируются с тремя типами внутренних (ведомственных) систем:

• системы документооборота;
• системы-источники данных для ответов на поступившие СМЭВ-запросы;
• системы-инициаторы межведомственных запросов (СМЭВ-решение выступает в роли транспорта в/из СМЭВ).

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

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

Второй сценарий связан с подготовкой результатов оказания услуги. Если услуга переводится в электронный вид до 5-ого этапа (предоставления результата в электронном виде), заявитель должен получить в личный кабинет на ЕПГУ электронный документ, свидетельствующий об оказании услуги. Для этого:

• СМЭВ-решение должно инициировать создание карточки документа в системе документооборота;
• документ должен быть подготовлен и передан из СЭД в СМЭВ-систему.

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

Формирование отчетов

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

Для создания полноценного функционала отчетов в ТЗ необходимо включить следующую информацию:

• перечень отчетов;
• состав выгружаемых данных (по каждому отчету);
• формат выгрузки данных (по каждому отчету);
• описание механизма работы конструктора отчетов (например, возможность выбора периода построения отчета, состава данных, порядка их отображения и др.).

Автоматизация процессов

Корректное описание автоматизируемых процессов – ключ к созданию качественной и удовлетворяющей потребности конечных пользователей СМЭВ-системы. Наиболее часто в подобных решениях автоматизируются следующие процессы:

• ответ на поступивший межведомственный запрос;
• направление уведомлений о событиях в системе;
• отдельные этапы обработки заявления на предоставление госуслуги (регистрация, направление связанных СМЭВ-запросов к поставщикам данных (в т.ч. проверка корректности представленных данных), отправка уведомлений пользователю на ЕПГУ и др.).

Для понимания и корректного описания всех нюансов автоматизируемого процесса автору ТЗ желательно пообщаться с конечными пользователями системы (операторами), узнать их видение процесса, его алгоритм, участников и т.д.

Структура ТЗ

Ниже в качестве примера представлен наиболее полный вариант структуры ТЗ на создание ИС для СМЭВ.

1. Термины и сокращения
2. Основные положения
   1. Наименование работ
   2. Сроки проведения работ
   3. Цель и задачи работ
   4. Нормативное обоснование работ
3. Объект автоматизации
   1. Цель и задачи системы
   2. Компоненты системы
   3. Пользователи
   4. Базовое ПО
   5. Функции системы
   6. Интеграции
   7. Реализованные госуслуги и сервисы межведомственного взаимодействия
4. Требования к реализации ИС
   1. Архитектура
   2. Базовое ПО
   3. Технологии (ОС, СУБД и проч.)
   4. Требования к интеграционному API
5. Требования к функционалу ИС
   1. Обеспечение оказания государственных услуг в электронном виде
   2. Обеспечение межведомственного взаимодействия с ВС поставщиков данных
   3. Обеспечение функционирования ведомственных ВС
   4. Автоматизируемые процессы
      1. Обработка заявлений
      2. Обработка СМЭВ-запросов
      3. Направления уведомлений
   5. Интеграция с ведомственными ИС
   6. Требования к обработке и хранению данных
   7. Требования к формированию отчетов
6. Требования к администрированию ИС
   1. Управление пользователями
   2. Управление правами доступа
   3. Журнал сессий
   4. Журнал действий пользователя
7. Прочие требования к ИС
   1. Брендбук и требования к интерфейсам
   2. Требования к режимам функционирования
   3. Требования к надежности
   4. Требования к безопасности и защите информации
   5. Требования к масштабируемости
   6. Требования к эргономике и эстетике
   7. Требования к лингвистическому обеспечению
   8. Требования к лицензионной чистоте
8. Целевые эксплуатационные характеристики
   1. Число пользователей
   2. Время отклика
   3. Время бесперебойной работы
   4. Качество обработки СМЭВ-запросов
      1. Скорость обработки
      2. Процент потерь
9. Результаты работ
   1. Этапы выполнения работ
   2. Результаты работ
   3. Сводная таблица работ, сроков и отчетных документов
10. Гарантия качества