Крепок ли фундамент?
62 неудобных вопроса
об электронном правительстве России

Под фундаментом «Электронного правительства» в этой статье TAdviser подразумеваются следующие технологии:

• межведомственное взаимодействие (СМЭВ),
• система идентификации (ЕСИА),
• порталы госуслуг - ЕПГУ (Единый портал госуслуг) или РПГУ (Региональные порталы госуслуг),
• АИС МФЦ (автоматизированная информационная система многофункционального центра предоставления услуг).

К ЕСИА нет вопросов

Начнём с наименее спорной технологии - ЕСИА (Единая система идентификации и аутентификации), которая позволяет авторизовано работать через интернет с государственными (и не только) системами. Сама по себе технология на середину 2018 года работает вполне прилично, её возможности позволяют создавать личные кабинеты приложений даже более функциональные, чем личный кабинет на ЕПГУ. Разработчики ЕСИА очень активно реагируют на высылаемые в их адрес замечания и оперативно устраняют выявленные неточности.

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

То есть ЕСИА работает, позволяет создавать приложения силами различных ИТ-компаний и вопросов вызывает минимальное количество.

Ключевая цель СМЭВ достигнута, но есть над чем работать

Продолжим со СМЭВ. Это самая недооценённая в плане PR государственная технология. Ключевое назначение СМЭВ - избавить граждан от ношения справок из одного органа власти в другой. Вспомните, ещё недавно была актуальна шутка: «Дайте справку, что у вас есть справка». Теперь этого нет в большинстве случаев. С этой точки зрения СМЭВ достиг своей цели и может/должен использоваться для показа достижений власти. По самым грубым оценкам благодаря СМЭВ от одного до десяти миллионов справок ежедневно НЕ ТРЕБУЮТСЯ с граждан и организаций. Если принять расходы на получение одной справки в 500 рублей (заявитель приехал, постоял в очереди, уехал, в некоторых случаях ещё и заплатил пошлину, сотрудник органа власти потратил время на приём посетителя), то ежедневная экономия составляет от 0,5 до 5 миллиардов рублей, которые тратились бы в противном случае не производительно.

В плане развития технологии можно задать следующие вопросы:

• Каков реальный уровень использования СМЭВ в стране? Т.е. количество запросов с разбивкой по поставщикам информации. Ранее такие данные публиковались, правда в машиноНечитаемом виде, что не позволяло их анализировать.
• Каково среднее количество запросов в разрезе конкретных видов сервисов на 1000 жителей? Как и почему оно меняется от региона к региону? (раньше Минкомсвязи публиковало исходные данные о количестве запросов, уровне использования).
• Стоит ли принуждать и как именно стимулировать «отстающие» регионы к использованию СМЭВ? Как организовать мониторинг так, чтобы он не провоцировал появление систем «накрутки»?
• Какие виды мониторинга сейчас работают, то есть какого рода отчёты можно получить? Есть ли отчёты по времени ответа на вопросы? Какие мероприятия проводятся для уменьшения времени получения ответов? Можно ли приблизить сроки ответов к одному дню?

Пояснение. Вопросы связаны с тем, что часть госуслуг не может быть исполнена юридически корректно из-за невозможности получить ответ в нормативный срок исполнения услуги. Есть услуги длительностью 5-7 дней, а нормативный срок ответа на межведомственный запрос составляет 5 дней.

• Есть ли отчёты по количеству «пустых» ответов (т.е. ответов типа «нет данных»)?

Пояснение. Множество ответов формируется автоматически за счёт подключения приложений к СМЭВ, но часть баз данных «пустые». То есть по формальным признакам сервис работающий, а данных для принятия решения система не даёт.

• Понимает ли Минсвязи уровень работоспособности СМЭВ Евразийской экономической комиссии (ЕАЭК)? Не планирует ли Минсвязи более активно участвовать в постановочной части СМЭВ ЕАЭК? Какова ситуация с наличием СМЭВ в странах Евразийского экономического союза (ЕАЭС)?

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

• Планируется ли разработать методику запуска Р-сведений в СМЭВ 3 (мы периодически сталкиваемся с отсутствием ответственного за вывод вида сведений в продуктивный контур)?

Итак, вопросы заданы, почти все они являются техническими, то есть относительно легко решаемыми.

Должен ли ЕПГУ стать единой точкой подачи заявлений?

Наиболее мифологизированная технология. В 2017-2018 гг. слышатся две взаимосвязанные идеи - через ЕПГУ представляются миллионы услуг и ЕПГУ должна стать единой точкой подачи заявлений.

Разберём первое утверждение. Для анализа возьмём данные по ЕПГУ за ноябрь 2017 г.^[1] и по порталу Москвы за сентябрь-октябрь 2017 г. ^[2]

При ближайшем рассмотрении оказывается, что почти весь трафик ЕПГУ (98%) составляют 4 информационных сервиса (таблица 1). Есть ещё шесть востребованных услуг, сумма которых составляет 2 млн обращений.

Количество обращений за информационными услугами через ЕПГУ (ноябрь 2017 года).

Количество обращений за федеральными услугами через ЕПГУ (ноябрь 2017 года).

Количество региональных услуг, предоставленных с ЕПГУ, не впечатляет - четыре самых востребованных услуги запрошены 52 300 раз за месяц, этот показатель вполне достижим на десятке хорошо работающих региональных порталов.

Количество обращений за региональными / муниципальными услугами через ЕПГУ (ноябрь 2017 года).

Количество обращений за услугами через Портал Москвы в сентябре и октябре 2017 г.

Выводы, которые напрашиваются из статистики:

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

2) Запись в очередь для получения конкретных очных услуг также очень популярна.

3) А вот услуги, в которых предполагается взаимодействие, не являются массовыми. Но такие услуги считать ненужными нельзя ни в коем случае. Далее мы будем рассматривать только не массовые услуги. Именно они составляют реальной объём проектов в части «электронизации», именно здесь сосредоточены проблемы.

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

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

С точки зрения последующего анализа обратим внимание на то, что возникают три точки изменения - форма заявки, сервис передачи заявки, ВИС.

Начинаем задавать вопросы.

• А правда ли, порталы госуслуг настолько хороши, что заведомо обладают функциональностью, равной подсистемам ввода абсолютно разнообразных по назначению ведомственных систем?

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

• А правда ли возможно повторить в отделённой от ВИС интерфейсной части все виды форматно-логического контроля, работу со справочниками, сутевую проверку заявки на основе имеющихся в ВИС данных? Реально повторить, а не сделать вид?
• Сколько стоит отделение интерфейса ВИС на Портал госуслуг? Не забудем, что кроме затрат на создание будут затраты на поддержание в актуальном состоянии.

Вот перечень затрат - в дополнение или вместо интерфейса ВИС создаётся интерфейс на портале госуслуг (для каждой подуслуги), создаётся веб-сервис приёма данных, создаётся подсистема обработки полученных данных. Анализ автора - минимум 800 тысяч рублей на одну услугу, состоящую из трёх подуслуг, вариативность услуги увеличивает затраты.

• Какова изменчивость интерфейсной части информационных систем в применении к формам заявлений на портале госуслуг? Сколько раз за год могут поменяться требования к форме в связи с изменением нормативных требований, опыта эксплуатации системы и т.д.?
• Можно ли обеспечить синхронное финансирование работ по изменению ведомственной системы и формы на портале госуслуг?

Пояснение. Для ответа на этот вопрос можно использовать письмо Минкомсвязи АК-П13-070-20462, датируется 28 августа 2017 г. Исходя из него следует, что «окно» изменений форм на ЕПГУ в 2017-м году было порядка 2-х месяцев.

Обратим внимание на то, что практика поддержания в актуальном состоянии ведомственных систем выработана и не слишком накладна.

• Что делать с услугой в случае изменения требований нормативной базы к ней и как следствие, изменения требований к заявке? Надо ли приостанавливать возможность подачи заявки до изменения всей цепочки (форма - сервис - ВИС)?
• Какова длительность существования более-менее сложных форм на портале госуслуг без замечаний после её вывода на портал госуслуг?

Пояснение. Из опыта автора - 3 месяца после интеграции, потребовавшей 3 месяца интенсивных работ со стороны ВИС и портала госуслуг.

• Какое количество услуг, выведенных на порталы госуслуг перестают соответствовать нормативной базе ежегодно? Что с ними делать, выводить из эксплуатации?

Иногда приходится видеть следующий ответ на проблемы изменчивости форм - «упрощенный подход», когда форма на портале состоит из 4-х частей:

а) Идентификационные данные заявителя на основе ЕСИА;
б) Идентификатор услуги / подуслуги;
в) Большое поле комментария (мол пишите, всё что хотите);
г) Поле для прикладывания файлов.
Можно утверждать, что значительная часть региональных электронных услуг - это вариация описанного случая.

Поэтому ставим дополнительные вопросы:

• А мы точно хотели получить такого рода автоматизацию? Какие есть выгоды в таком варианте?
• Что же такое заявление? Структурированный набор данных, подлежащий в том числе автоматизированной обработке или информационная помойка, которую надо просто доставить до специалиста?

Помимо технических проблем рассмотрим организационные особенности вывода форм на порталы госуслуг на примере ЕПГУ.

Нынешняя процедура вывода услуг на Портал выглядит следующим образом:

а) разработчик создаёт/адаптирует ВИС,
б) разрабатывает вид сведений приёма заявления (2 недели),
в) регистрирует его в тестовой среде (14 рабочих дней),
г) создаёт ТЗ на портальную форму (2 недели),
д) отдаёт его разработчику формы.

Если есть ошибки, несоответствие технологическим возможностям Портала, то происходит коррекция почти всей цепочки (длительность коррекции составляет один - два месяца). Далее, после вывода формы в тестовой среде ЕПГУ и успешного тестирования формы при положительном результате вид сведений регистрируется в продуктивной среде (14 рабочих дней) и форма заявления выводится в продуктивной среде ЕПГУ.

• Только автору эта схема кажется не оптимальной?

Укажем дополнительные параметры процесса. Сейчас в согласовании требований к форме услуги участвуют специалисты Минсвязи (регламент их деятельности не понятен, добавим 2 недели между пунктами г) и д)). В результате возникают ещё вопросы:

• Какова процедура вывода услуг на ЕПГУ? А именно какие права есть у сотрудников Минсвязи при согласовании ТЗ на ЕПГУ? Как регламентирована процедура работы сотрудников Минсвязи при согласовании ТЗ?
• Есть ли утверждённая методика, в которой описывается, что именно можно включать в форму на ЕПГУ, а что является экспертным мнением сотрудников Минсвязи?

Пояснение. Вопрос навеян реальным опытом.

• Какие обязанности есть у сотрудников Минсвязи при согласовании ТЗ? Какую ответственность они несут за нарушение сроков согласования ТЗ, а главное - за конечный результат?
• Можно ли при заключении контракта заранее угадать срок окончания работ с учётом работы сотрудников Минсвязи по согласованию ТЗ?

«Типовые услуги» - заявления, заполняемые заявителем на ЕПГУ с использованием формы-концентратора, отчасти решают проблему, но только в части стоимости/сроков первичной интеграции.

Итак, мы рассмотрели достаточное количество вопросов для формирования ответа на поставленный в начале вопрос: «должен ли ЕПГУ стать единой точкой подачи заявлений»?

Если вы ответите положительно, то хорошо бы подкрепить это статистикой и приложить смету. И статистику хорошо бы посмотреть с экспертами - в последнее время органы власти для достижения контрольных показателей подают запросы сами себе. Пример. По отдельным видам услуг нормативно установлена контрольная цифра - 30% заявок должно подаваться через порталы. На практике сотрудники органа власти в конце рабочего дня «набивают статистику», подавая себе заявки.

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

«Конструктор госуслуг» - это вид информационных систем, обеспечивающих конструирование формы заявления, нескольких интерфейсов исполнителя - приём заявки, предоставление ответа. Изначально эти системы являлись или продолжением регионального портала госуслуг, или умели интегрироваться с порталами через веб-сервис. Подход возник достаточно давно и реализован с разной степенью успеха.

Думается, что использование конструктора, особенно при бессервисной интеграции, являлось попыткой реализовать концепцию быстрого перевода ВСЕХ услуг в электронный вид (такие требования выдвигались в 2012-2014 годах). Нам всем (разработчикам и заказчикам) виделось, что мы нашли ответ на поставленную задачу. Казалось шаг, ещё шаг, вот мы уже внедряем ...

Использование систем на базе конструкторов бывает в двух вариантах - доставка заявки (с ограничениями, описанными выше) с дальнейшим ручным перекладыванием в реальную ведомственную систему или реализация процесса исполнения услуги. Второй вид использования имеет некоторый смысл, но он ограничен по времени - надо переходить к нормальным ведомственным системам. Мы опять-таки приходим к тому, что такое ведомственная информационная система, можно ли её создать по идеологии low code (без программирования), можно ли процессные системы создавать на базе реестрового подхода (большинство конструкторов услуг - это реестровые системы, а исполнение госуслуг имеет явно выраженные признаки двух подходов - процессного и реестрового).

Указанный выше «упрощенный подход» является массовым, можно утверждать, что 50%-90% услуг на региональных порталах сделаны именно по этой технологии.

Задаём вопросы:

• Можно ли сделать на базе конструктора реальную сложную ВИС без программирования?
• Каково реальное использование электронных услуг, созданных на конструкторах? Посмотрите на опыт внедрения, проанализируйте количество реального использования услуг на базе конструкторов.
• Сколько работающих услуг окажется после анализа?
• Как выходить из этой ситуации, ведь простое «списание» услуг с региональных порталов вызовет массовые проверки со стороны прокуратуры?

Конечно, указанные выше вопросы должны решаться более разумно с точки организации работ, но даже этот список - второстепенные вопросы. Главный вопрос - а зачем нам нужен портал госуслуг? Причём этот вопрос можно разбить на две части:

1) Что нам даёт портал как точка подачи заявки на электронное предоставление услуг?

2) Что нам даёт описательная часть (перечень описаний услуг, административных регламентов)?

Итак, что нам даёт портал как точка подачи заявки на электронное предоставление услуг? Каждый может придумать своё объяснение. Авторское звучит так - портал позволяет фиксировать факт и дату подачи заявки; в личный кабинет портала передаётся результат предоставления услуги. Вроде бы похоже на то, что есть? Уточним, при этом на портале госуслуг стоит заполнять самый минимум (данные о заявителе, название подуслуги), заявка передаётся через веб-сервис, специфичная часть формы заявки дозаполняется в ведомственном личном кабинете. То есть кардинально снижаются все виды расходов на интеграцию.

Ещё раз подчеркнем, что отказываться совсем от портала (ЕПГУ или РПГУ) как от точки первоначальной подачи вряд ли разумно. Эти порталы несут функции внешней фиксации факта подачи. Личные кабинеты фиксируют показанные результаты. И эта функция дополняет ключевую идею - разработка ведомственных систем в интересах конкретного органа власти, как мы подчёркивали ранее.

Фиксация времени начала запроса услуги чрезвычайно полезна как для конкурентных услуг (например, запись в летний лагерь), так и для контроля времени предоставления услуг, количества отказов.

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

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

Хочется отметить, что ответы на эти вопросы не совсем простые и не могут быть собраны путём простого анализа статистики регионов или федералов.

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

Теперь перейдём к описательной части порталов госуслуг.

Уже много лет мы видим, что описательная часть порталов госуслуг мало меняется - на портале присутствует «плоский» список услуг и функций, то есть бизнес-процессов власти. Но эти «деревья» не представляются «лесом», то есть невозможно визуализировать сквозные процессы. Автору доводилось видеть портал бизнес-процессов крупной организации. По сути очень похоже на ЕПГУ, но есть два отличия:

а) список устроен иерархически, то есть идёт группировка на уровни процессов - от макро описания до детализации. Кажется, что такой подход более логичен для формирования согласованного списка функций органов власти.
б) есть технология контроля деятельности подразделения, которая опирается на описание процесса (административный регламент), такой подход стимулирует отслеживать владельцем процесса следить за качеством описания услуги.

Можно привести ещё несколько идей, реализация которых пойдёт на пользу ЕПГУ и РПГУ. Например, в строительной отрасли удалось подсмотреть «Калькулятор строительных процедур»: поверх списка процедур сделана система для расчёта траектории взаимодействия застройщика с государством при осуществлении строительства. На ЕПГУ подобные функции появляются в разделе «Жизненные ситуации», но они «живут» сами по себе, не опираясь на существующую информацию об услугах и исполнителях услуг.

Кратко сформулируем наиболее очевидные вопросы по описательной части:

• Есть ли смысл провести структуризацию услуг и функций?
• Есть ли смысл организовать расчёт и визуализацию некоторых траекторий (на уровне описаний) для типовых жизненных ситуаций с подтягиванием значений из имеющихся справочников?
• Есть ли смысл использовать порталы госуслуг как точку профессионального консультирования?

В профессиональной среде эталоном реализации такой функции выступал Нижегородский портал госуслуг.

Функции АИС МФЦ повергают в изумление

Многофункциональные центры (МФЦ) реально решили множество проблем, упростили общение с властью, являются удачным государственным проектом. При этом физика этого процесса до конца не понятна. Посудите сами - вместо профессионала из органа власти (например, соцзащиты), который разбирается в вопросе, вы заполняете бланк под присмотром «универсального специалиста». Не забудем о текучке кадров в МФЦ, и остаётся только удивляться, как эта конструкция может быть такой полезной. На взгляд автора, основная причина в том, что в МФЦ удалось обеспечить гарантированный приём посетителей в короткий срок за счёт перераспределения операторов с участка на участок в зависимости от нагрузки.

А вот функции Автоматизированной информационной системы (АИС) МФЦ повергают в изумление. Смотрите, в основе МФЦ рассмотренные ранее конструкторы услуг, обрезанные до приёма первичной формы, без исполнения. Между АИС МФЦ и ВИС проложен в общем случае неавтоматизированный путь (курьер, привозящий заполненный бланк заявления). В 2018 году вроде бы начался переход на передачу сведений из АИС МФЦ в ВИС через СМЭВ (автор надеялся, что этот переход начнётся ещё в 2013 году). И здесь мы упираемся в рассмотренную ранее задачу - интерфейс ввода отделён от собственно системы. Всю глубину задачи можно понять на примере разработки форм для заведомо сложных услуг Росреестра. Традиционно зададим вопросы:

• Неужели интерфейсная часть Единого государственного реестра недвижимости (ЕГРН) так проста, что её можно сделать на каком-то «конструкторе услуг»?
• Правда ли кто-то помимо разработчика ЕГРН или кого-то из «старых» разработчиков системы ведения кадастра может сделать это, заодно погрузившись в предметную область?

Пояснение. Вспоминается совет/вопрос, данный автору С.А. Сапельниковым (Росреестр) - «А как вы собираетесь написать сервис межведомственного запроса к нам, не разобравшись в специфике нашей отрасли?» То есть главный информатизатор Росреестра считал, что даже для запроса выписок надо изучить предметную область знаний.

• Если это так легко, то почему процесс создания ЕГРН растянулся на полтора года?

Пояснение. Вряд ли задачка является примитивной.

• Правда ли, что самая нервная система в части СМЭВ (разработка сервисов для интеграции с Росреестром - самая сложная задача) будет проста для реализации в АИС МФЦ?
• Является ли примитивной задача переобучения сотрудников МФЦ работе с новой версией ПК ПВД?

Рассмотрим «простые услуги», которые автор неплохо знает - Разрешение на строительство, разрешение на ввод в эксплуатацию. Они требуют сотни страниц документации даже для простых объектов. Поэтому задаём вопрос:

• Как можно внести бумажную документацию в многофункциональном центре и не разорить его на часы сканирования, покупку сканеров формата А3 или больше?

Уверен, что многие другие услуги накладывают свою специфику и там тоже можно задать вопросы, не имеющие ответов.

Поэтому зададим заключительные вопросы:

• Реально ли включить АИС МФЦ в сквозную цепочку предоставления услуг в цифровом виде?
• В какую сторону стоит развивать АИС МФЦ?

Заканчивая про АИС МФЦ надо не забывать об очень интересном направлении - ИС МДМ (Государственная информационная система мониторинга предоставления государственных и муниципальных услуг на базе МФЦ). Если эта технология полноценно заработает, можно будет тиражировать такой подход, да и прямой эффект будет значительным.

Вместо заключения

Зачем нужно задавать указанные вопросы? Затем, чтобы понять текущее состояние дел и причины по которым мы здесь находимся. Автору кажется, что действительность и наше мнение о ней кардинально расходятся. Давайте разберёмся и будем двигаться с открытыми глазами.