Федеральный портал государственных услуг запущен, первые сервисы работают. Теперь очередь регионов: распоряжение Правительства от 17 декабря 2009 года № 1993-р требует перевести приоритетные услуги в электронный вид по графику до 2014 года. Регионы строят собственные порталы и реестры и почти сразу упираются в одну проблему. Услугу мало нарисовать на портале. Её нужно довести до ведомственной информационной системы, которая реально принимает заявление, проверяет данные и выдаёт результат. Это задача интеграции, и решается она не на уровне веб-формы.

Тиражирование вместо разработки с нуля

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

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

СМЭВ как обязательный слой

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

Практическая разница между федерацией и регионом – в масштабе и неоднородности. Федеральный сервис обслуживает один регламент и одну систему-владельца данных. Региональный шлюз агрегирует десятки муниципальных потоков с разной нагрузкой и качеством данных. Когда число параллельных заявлений растёт скачками – приёмная кампания, сезон выплат, – реляционная база реестра обращений становится узким местом. Часть нагрузки логично вынести на хранилища, спроектированные под горизонтальное масштабирование; мы разбирали этот подход в заметке про NoSQL для масштабирования.

Где регионы спотыкаются

Три типичные ошибки повторяются от субъекта к субъекту.

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

Вторая – игнорирование статусной модели. Заявитель хочет видеть, где его заявление: принято, на проверке, готово. Без сквозного проброса статусов из ведомственной системы на портал доверие к сервису падает, нагрузка возвращается в окна МФЦ.

Третья – недооценка неструктурированных данных и распознавания. Скан паспорта или справки – это не поле базы. Регионы рано или поздно столкнутся с задачей машинной обработки таких документов; на горизонте – системы, которые анализируют естественный язык и слабоструктурированные данные, как показал недавний эксперимент IBM Watson. Закладывать архитектуру стоит с расчётом на это.

Вывод

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