Многоканальный доступ к государственным услугам

Гражданин подаёт заявление на пособие через приложение, получает отказ по формальному основанию, звонит в колл-центр — и там его просят продиктовать те же данные заново, потому что оператор не видит историю обращения. Затем он едет в МФЦ, где сотрудник смотрит третью систему и просит донести бумажную справку, которую гражданин уже загружал в приложении. Это не сбой в одном канале. Это и есть типичная государственная услуга без омниканальности — три ведомства работают безупречно, а опыт человека разваливается на стыках.

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

Чем омниканальность в госуслугах отличается от мультиканальности?

Разница не в количестве каналов, а в том, что происходит с делом гражданина при переходе между ними. Мультиканальная модель добавляет цифровые фасады к тем же изолированным back-office системам: заявление в приложении и заявление в окне МФЦ хранятся в разных базах, и статус, видимый в одной, не виден в другой. Омниканальная модель строится вокруг единого дела (case), а не вокруг канала — приложение, портал, колл-центр и офис становятся разными интерфейсами к одному и тому же процессу.

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

Почему гражданам приходится каждый раз начинать заново?

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

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

Чем несвязанные каналы отличаются от простой неэффективности — и почему это sludge, а не трение?

Ричард Талер и Касс Санстейн ввели разграничение между обычным трением (friction), которое просто требует усилий, и sludge — искусственно созданным или неустранённым трением, которое отбивает у человека желание довести взаимодействие до конца в интересах системы, а не человека. Они подробно развивают эту идею в переиздании книги «Nudge: The Final Edition» (Thaler & Sunstein, 2021).

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

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

Кто теряет больше всего, когда каналы не связаны между собой?

Разорванность каналов не распределяется поровну. Она сильнее всего бьёт по тем, кто меньше всего может себе позволить лишний визит или лишний час на линии:

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

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

Как выстроить омниканальную архитектуру государственных услуг на практике?

Здесь легко скатиться в абстракцию про «единую цифровую платформу». На практике омниканальность строится в определённой последовательности, и пропуск шагов почти всегда приводит к дорогому фасаду без реальной связности.

1. Составьте карту одного дела, а не карту одного канала. Возьмите реальный жизненный сценарий — регистрацию новорождённого, смену адреса, оформление пособия — и проследите его через все каналы, которыми реально пользуются граждане. Это и есть база для карт клиентских путей, но применительно к гражданину, а не к клиенту коммерческой компании.
2. Определите единственный источник правды для статуса дела. Не портал, не CRM колл-центра, не бумажный реестр МФЦ — а одна система, к которой все остальные каналы обращаются как к оракулу. Без этого шага любая интеграция будет временной заплаткой.
3. Спроектируйте переходы между каналами как часть услуги, а не как исключение. Что происходит, если гражданин начал заявление в приложении, а закончить решил в окне МФЦ? Это должно быть таким же продуманным сценарием, как основной путь, а не аварийным исключением, которое сотрудники решают на своё усмотрение.
4. Установите дефолт «не спрашивать дважды» как правило проектирования, а не пожелание. Это применение архитектуры выбора: если система уже знает факт, поле должно быть предзаполнено, а не пустым. Изменение дефолта с «спроси заново» на «подтверди уже известное» — один из самых дешёвых и самых недооценённых рычагов снижения sludge.
5. Согласуйте регламенты между ведомствами до внедрения технологий. Большинство разрывов каналов — это не технический долг, а организационный: два ведомства не договорились, кто первым получает обновлённые данные. API не решает вопрос владения процессом.
6. Тестируйте на пограничных сценариях, а не на идеальном пути. Человек без смартфона, человек, потерявший бумажную справку, человек, у которого истёк срок документа посередине процесса, — именно эти случаи показывают, держится ли омниканальность на самом деле.
7. Замерьте до и после на уровне сквозного дела, а не на уровне отдельного канала. Удовлетворённость приложением может расти, пока общая нагрузка на очные окна не падает — это признак фасадной, а не сквозной омниканальности.

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

Какие примеры показывают, что связность каналов реально возможна?

Эстонская модель межведомственного обмена данными X-Road — один из наиболее цитируемых примеров инфраструктуры, где данные, однажды введённые гражданином, доступны всем уполномоченным ведомствам без повторного запроса; описание принципа доступно на e-Estonia. Это не про интерфейс — это про инфраструктурное решение «спроси один раз», лежащее в основе связности каналов.

Другой ориентир — подход британской государственной цифровой службы, зафиксированный в GOV.UK Design System: единые паттерны интерфейса и формулировок применяются across ведомств именно для того, чтобы переход гражданина между разными государственными сервисами не ощущался как смена логики каждый раз заново. Это иллюстрирует принцип согласованности пути — один из фундаментальных элементов клиентского опыта, применённый на уровне целого государства, а не отдельной услуги.

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

Как измерить, работает ли омниканальность на самом деле?

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

Три практических индикатора говорят о реальной, а не фасадной омниканальности:

• Доля дел без повторного ввода данных — сколько заявлений проходят весь путь без того, чтобы гражданин повторно предоставлял уже переданную информацию.
• Доля переходов между каналами без потери контекста — оператор колл-центра или сотрудник окна видит полную историю дела с первой секунды разговора, без просьбы «напомните, пожалуйста, номер и суть обращения».
• Нагрузка на самый дорогой канал (очный) в динамике — если она не снижается после запуска цифровых каналов, значит, цифровые каналы не заменяют, а дублируют очные, что прямо указывает на разрыв связности.

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

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

Что мешает госорганам внедрить омниканальность даже при наличии бюджета?

Самое частое препятствие — не деньги и не технологии, а структура ответственности. Цифровой портал принадлежит одному департаменту, колл-центр — аутсорсинговому подрядчику, очные окна — региональным подразделениям. У каждого свой KPI, свой бюджет и свой начальник. Никто не отвечает за дело гражданина целиком, а значит, никто не заинтересован чинить разрывы на стыках — они технически «не моя зона».

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

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

С чего начать, если ресурсов на полную трансформацию нет?

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

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

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

Что из этого стоит запомнить прежде всего

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