Государственная электронная коммерция

Общая схема взаимодействия через СМЭВ

Время на прочтение

В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.

Вспомни, как раньше было сложно получить любую справку или переоформить какой-нибудь договор. Прийти пораньше, занять очередь, отстоять в ней три часа, поменять сто кабинетов — настоящий бюрократический ад. Государственные электронные сервисы сделали нашу жизнь намного проще. Мы поговорили с экспертом компании STM labs, чтобы разобраться, как они работают и как специалисты разрабатывают для них ПО.

Вступление

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

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

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

Виды сведений

Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.

Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.

На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.

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

Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:

Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:

На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.

Обмен по универсальному виду сведений можно представить так:

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

Данные формы, заполненные пользователем портала, пакуются во вложение к основному сообщению.

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

Особенности государственных электронных сервисов

Разработка таких сервисов даже на начальных этапах сильно отличается от создания других приложений. И главное, на что делается упор, — это безопасность. Производители государственных систем должны строго ориентироваться на существующий регламент, глубоко понимать нормативную базу. Это позволяет выстраивать логику процессов в системах правильно и эффективно. По словам эксперта компании STM labs, в этом состоит и сложность:

Некоторые, на первый взгляд, простые вещи после изучения пластов нормативной базы такими уже не кажутся. Ведь государственный сервис в России — это сервис для десятков миллионов людей. При таком масштабе в живом организме экономики встречаются сотни самых разных особенностей и частных случаев. А это все необходимо учитывать и поддерживать.

Еще одной особенностью таких сервисов является выдерживание большой нагрузки и работа на высокой скорости, несмотря на поток посетителей. Мы спросили у специалиста STM labs, как такая «‎выносливость» обеспечивается с технической точки зрения.

Сервисы ФНС, с которыми мы работаем, базируются на продвинутой и сложной архитектуре, включающей в себя передовые разработки. Системы развернуты на мощных кластерах, используют заточенные на высокую нагрузку инструменты, такие как СУБД PostgreSQL и Clickhouse, элементы стека Hadoop и другие. С сервисами ФНС в нашей компании работают десятки опытных специалистов, которые ведут свои проекты от запуска и не бросают их после, всегда оперативно решают любые проблемы и сложности.

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

Как STM labs работают с государственными сервисами

Компания STM labs задействована в работе целого ряда систем ФНС. Самая известная — это НПД (налог на профессиональный доход). Над ее созданием они работали вместе со специалистами из ГНИВЦ. Эта система включает огромную платформу с миллионами пользователей и большим потоком транзакций, проходящих через нее. Платформа ставит пользователей на учет, принимает от них данные о доходах, считает налоги, обеспечивает работу веб-версии личного кабинета и мобильного приложения, предоставляет аналитические и административные элементы для ФНС.

Помимо этого, аналогичный опыт разработки был в 2022 году с новым экспериментом ФНС — автоматизированной упрощенной системой налогообложения. Кроме систем, нацеленных на налогоплательщика, STM labs также работает с целым семейством внутренних систем ФНС, обеспечивающим работу отдельных бизнес-процессов этой массивной государственной структуры.

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

Мы попросили эксперта компании поделиться своими впечатлениями от работы с госсектором и рассказать о взаимодействии с сервисами ФНС:

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

Основная мысль, которая определяет подход ФНС к проектированию, звучит так: «‎Как нам сделать работу наших систем настолько прозрачной и удобной, что налогоплательщику будет просто легче исполнить свои обязательства и не изыскивать пути обхода закона?»

Постановка цели от позитива — подход, наиболее конструктивный в любой сфере. Он позволил команде STM и ФНС создать продукт, который нашел отклик у пользователей:

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

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

Постановка задачи

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

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

В следующих статьях мы рассмотрим, как на стороне поставщика сведений организовать обработку заявлений по данным пользователя с использованием движка автоматизации бизнес-процессов Workflow Core.

Участники взаимодействия

Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.

Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).

Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.

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

Очереди сообщений и процесс взаимодействия

В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.

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

Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.

На каждый запрос может поступить как успешный, так и неуспешный ответ.

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

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

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

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

Анализ явления электронной услуги

Работать с людьми легко. Трудно работать с живыми людьми.
Александр Кулич.

Что же такое электронная услуга, в хорошем смысле этого слова?

Электронная услуга и процесс ее оказания

Пройдемся по определениям. И начнем с услуги в общем:

Услуга — результат, по меньшей мере, одного действия, обязательно осуществлённого при взаимодействии поставщика и потребителя, и, как правило, нематериальна (1).

А теперь напустим виртуальности:

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

И вот еще интересное уточнение:

Электронные услуги являются разновидностью информационных услуг. Электронная форма означает возможность визуализации продукта или услуги с помощью автоматизированных или компьютерных средств визуализации (2).

Как же взаимодействие с электронной услугой может проистекать живьем?

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

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

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

Рисунок 1. Процесс заказа электронной услугой

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

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

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

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

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

Таким образом у нас сформировался следующий алгоритм:

С процессом вкратце разобрались. Перейдем к сути.

Окружение электронной услуги

Итак, что мы имеем?

Действующие лица: Потребитель услуги и ее Исполнитель.

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

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

Наверняка Вам приходилось лицезреть публичное унижение человека — терминалом электронной очереди, в банке, на почте или МФЦ. Путем выбора подсказок – классификаторов, человек мучительно, шаг за шагом, а иногда и пятясь по экранам назад, формулирует свой интерес, в хорошем смысле этого слова. Происходит это потому, что те слова, которые он видит на экране терминала, не всегда совпадают с теми, которыми он описывает потребность в свей голове. И вот ему уже пару раз подсказали нужную комбинацию, и вот он уже, подходя к терминалу в следующий раз, ловко тыкает пальцами в определенные места экрана, в определенной последовательности. И даже слова в его голове подбираются уже нужные. Но через время оказывается, что разработчики ПО, идя на встречу пожеланиям заказчиков, из самых лучших побуждений, все кардинально поменяли, И блуждания в лабиринтах экранов возобновляются.

В более широком понимании, пользователь интернет пространства может поискать по разного рода наводящим запросам, соответствующую услугу на просторах глобальной сети и подобрать себе должную.

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

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

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

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

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

Рисунок 2. Окружение электронной услугой

Недавно мне посчастливилось стать участником действа по предоставлению мне электронной услуги. Ну как электронной, скажем так полуавтоматической. То есть в МФЦ, девушка приятной наружности, как раз и заполняла мою заявку, связанную с оформлением документов. В заявке были обязательные реквизиты, для заполнения которых, у меня не было актуальных данных, да и на мой взгляд, они абсолютно были не неважны по сути дела. Уговорил я девушку, уговорил хорошую, пропустить эти реквизиты под мою расписку о том, что я осознаю всю возмутительность своего поступка и предупрежден о возможных последствиях. И что ж? Потеряв больше недели времени, получил ответ, что не хватает данных, для предоставления услуги. Кого я хотел обмануть?

Тут уместно упомянуть цитату из фильма «Гражданин Икс»:

«Сила бюрократии определяется ее способностью отказать в особом подходе кому бы то ни было».

Способы взаимодействия с электронной услугой

Итак мы выяснили, что одной из важнейших характеристик электронной услуги является место доступа к ней и формат представления для нее информации. Это пожалуй единственный мостик, перекинутый между ее реальной и виртуальной стороной.

Изъясняясь точнее, электронная услуга должна обязательно иметь интерфейс, то есть способ взаимодействия с собой. И еще необязательно — визуальное представление этого способа. Например, форму для заполнения данных пользователем c какого-нибудь сайта, на рисунке 3 – Портал услуг.

Полученный с портала запрос на оказание услуги попадает в виде заявки через интерфейс услуги в механизм ее обработки. В конечном счете, в этом самом механизме и генерируется результат, который возвращается обратно на портал в виде информации для потребителя.
Как упоминалось выше, у электронной услуги может и не быть визуального способа взаимодействия с пользователями, в том случае, если она употребляется исключительно другими электронными сервисами, как вспомогательная. На рисунке 3 — Услуга №2.

Рисунок 3. Взаимодействие с электронной услугой

Например, при отправке на сервис «Яндекс карты» (доступного в интернете) почтового адреса, можно получить в ответ его географические координаты. Или скажем, нужно уточнить для чьей-то заявки индекс, не тревожа лишний раз при этом заявителя. В таком случае электронная услуга должна определить, что в заявке не заполнен индекс, сама запросить его у сервиса «Почтовые индексы», по заполненному в заявке почтовому адресу и вписать полученный результат в заявку, без лишней волокиты и расспросов. Это и есть пример использования того самого, упомянутого нами ранее, узла по исполнению пожеланий.

В следующей части Часть 2. Электронная услуга мы поговорим об электронных кабинетах и учреждениях.

1. Солодков, Михаил Васильевич. Большая советская энциклопедия. Москва: б.н., 1969—1978 г.
2. Поляков А.А., Цветков В. Я. Информационные технологии в управлении. 2007: МГУ Факультет государственного управления.

Плюсы и минусы цифровизации

Главный и очевидный плюс цифровизации — это удобство. С выходом каждого нового приложения наша жизнь становится проще: оплатить коммуналку или налог можно онлайн, а за справкой о болезни не надо стоять в огромной очереди. Есть и другие преимущества, например, сокращение бюрократии и искоренение коррупции. Это происходит благодаря оптимизации государственного управления. Цифровые услуги помогают государству глубже понимать запросы общества, выявлять и удовлетворять его потребности.

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

Попробуй вспомнить: твоя бабушка хоть раз пользовалась Госуслугами? Отрицательный ответ не удивителен, ведь поехать на другой конец города и отстоять очередь — привычное для нее занятие. Более того, многие пожилые люди просто не доверяют цифровым технологиям, разговор с живым человеком в МФЦ для них куда надежнее чат-бота в приложении.

Еще один минус цифровизации — это киберпреступность. Именно поэтому специалист компании STM labs говорит о большом внимании к безопасности при разработке государственных электронных сервисов. В противном случае у киберпреступников будут развязаны руки, и они смогут делать с системой, что угодно.