Электронные муниципальные услуги: революционная идея

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

I. СНАЧАЛА ДАВАЙТЕ РАЗБЕРЕМСЯ, ЧТО ТАКОЕ МУНИЦИПАЛЬНАЯ УСЛУГА. 
Зайдите в администрацию Екатеринбурга, пройдите по первому или второму этажу (благо, чтобы попасть в здание городской администрации, не требуется даже никаких документов - вход свободный!), и вы увидите, что на дверях очень многих кабинетов прикреплены листочки формата А4, представляющие собой перечень пунктов. В тех случаях, когда перечень не умещается на одном листочке, оформляется пластиковый стенд, листочки засовываются в кармашки стенда, стенд размещается рядом с кабинетом. В перечне написано что-то вроде: "1. Справка от работодателя по форме 2-НДФЛ; 2. Справка из паспортного стола о количестве проживающих в квартире; 3. Справка из ЕРЦ о сумме ежемесячного платежа за квартиру; 4. Справка из ФРС, подтверждающая право собственности на квартиру, или договор социального найма; 5. Заявление; 6. ...". Перечень я только что взял с потолка, но вы наверняка видели такие перечни, а если не видели - то, повторюсь, сходите в городскую администрацию и посмотрите.  (Перед тем, как покинуть здание ратуши, не забудьте съесть хачапури, трубочку с белковым кремом и/или пирожное "Рикки" в буфете на первом этаже, с видом на ледовый городок. Ассортимент блюд и прайс-лист одинаковы во всех многочисленных буфетах и кафе, разбросанных по зданию городской администрации. Буфет слева от главного входа выигрывает конкурентную борьбу благодаря виду из окна и исключительной позитивности и дружелюбию буфетчицы Надежды).  
Что означает такой перечень? Он определяет условия, наличие которых необходимо для получения той или иной муниципальной услуги. Например, придуманный мной перечень документов вполне может быть использован при предоставлении услуги "Постановка на учет в качестве нуждающегося в получении субсидий по оплате жилья". Вот это и есть типичная муниципальная услуга. Еще: "Постановка в очередь на место в муниципальном детском саду". Еще "Выдача справки о чем-нибудь". Еще: "Предоставление информации из какого-нибудь реестра". В мэрии - несколько сот кабинетов, примерно на каждом пятом из них висит бумажка с перечнем - здесь предоставляются десятки муниципальных услуг. (Не только физическим лицам, но и юридическим: так, Главархитектура выдает какие-нибудь разрешения на строительство - "1. Технические условия на подключения к сетям. 2. Договор аренды земельного участка. 3. Эскизный проект. 4. ...").
И именно в эту проблему мы упирались каждый раз, когда в формате коллективного обсуждения пытались спроектировать перевод в электронный вид какой-нибудь, пусть самой простой электронной услуги, типа постановки на очередь в детский сад. Это кажется, что это просто: а когда начинаешь продумывать в деталях, то вылезает какая-нибудь "Справка из органов попечительства (для опекунов)" или "Медицинская форма №12345" или хотя бы просто "Подтверждение проживания одного из родителей в данном районе города" - ведь встать на очередь у нас можно не абы где, а только по месту жительства. Ну и откуда им взяться, спрашивается? 
В нынешнем, бумажном процессе предоставления муниципальной услуги, все выглядит грустно, но просто: заявитель (тот, кто претендует на получение услуги) вооружается перечнем, обегает все органы, дающие разного рода "Справки о наличии...", "Формы №..." или "Техусловия на...", приносит всю эту пачку в нужный кабинет - бинго! (Ну, в реальной жизни есть конечно и всякие другие проблемы, типа того, что некоторые справки имеют свойство "протухать", или что даже идеальный комплект документов может ничего не гарантировать без, ну, вы понимаете... но это все мы сейчас оставим за кадром). Проблема в том, что этот весь процесс - он весь сугубо бумажный. Само заявление - простенькую форму - заявитель, конечно, мог бы заполнить онлайн, но все эти справки - приложения к нему, - он должен все равно собрать и принести. Ну а раз все равно надо ходить, то какая разница? Можно и заявление принять на бумаге. От того, что оно будет электронным - никому никакой радости, ни заявителю, ни муниципальному органу. 

II. "ЛОБОВОЙ" ПОДХОД К СОЗДАНИЮ ЭЛЕКТРОННОЙ УСЛУГИ. 
ОК, думали мы, значит, чтобы сделать процесс предоставления услуги полностью электронным, надо и все эти справки-приложения сделать тоже электронными. Чтобы, значит, наш заявитель мог отправить в электронном виде весь пакет документов, одним кликом. Заполнить экранную форму, потом аплоад-фром-файл, аплоад-фром-файл, аплоад-фром-файл, потом сабмит - и готово, ага? 
Вот тут-то и начинается затык. И не один, а несколько. 
1. С чего мы взяли, что все эти многочисленные ведомства, в которых надо взять "Справки о...", готовы передавать нам эти справки в электронном виде? Что у них вообще есть электронные форматы для этих справок? Что они готовы их отдавать наружу? 
2. Даже если и так, как мы будем обеспечивать валидность справок? Каждое из этих ведомств будет подписывать свои электронные справки своей ЭЦП? Мы как-то сможем их проверить? Будет какое-то единое пространство доверия? И когда мы их передадим в муниципальный орган, тот тоже сможет проверить все подписи? 
3. Пусть мы смогли получить все справки от всех ведомств в электронном виде, и как-то решили проблему доверия к их содержимому. Все эти справки - в разных форматах. Мы их заливаем как приложения к нашему заявлению на муниципальный портал электронных услуг - как там должны понять эти форматы? А если это не машиночитаемые файлы определенного формата, а просто вордовские документы, или, скажем, сканы в pdf-ках (какой-ниубдь кадастр, или копии архивных документов) - получается, в муниципальном органе потом должны будут их распечатать, чтобы иметь возможность дальше обрабатывать? 
Короче говоря, надо задать себе совсем небольшое количество вопросов, чтобы остаться один-на-один с честным ответом: такая автоматизация "в лоб" (когда мы просто берем все "бумажные" процессы реального мира, и пытаемся сделать их электронными) - не проходит. Нереальна, неосуществима, и, главное, даже если каким-то чудом и будет осуществлена - не приведет к снижению трудозатрат всех участников процесса оказания услуги. 

III. МОДИФИКАЦИИ БЕСПОЛЕЗНЫ. 
На августовской встрече мы, наконец, в полной мере осознали бесполезность "автоматизации в лоб", и стали много думать об окольных путях. Сходу придумалось очевидное: а пусть тогда все эти ведомства напрямую предоставляют информацию в муниципальный орган, оказывающий услугу! Есть же такое модное слово - "межведомственное взаимодействие". Давайте сделаем так: мы обращаемся на муниципальный портал услуг, там оставляем только заявления, а все справки он запрашивает из разных ведомств самостоятельно. Красота? 
Не очень. 
1. Во-первых, слова про "межведомственное взаимодействие" есть, а самого межведомственного взаимодействия, на практике, нет. Ни форматов данных, ни стандартных транспортных протоколов. Никакой всероссийской межведомственной "шины данных". Чтобы муниципалитет начал получать на регулярной основе информацию у какой-нибудь налоговой инспекции, ГИБДД, БТИ или ФМС, люди должны сначала встретиться, обо всем договориться, и потом это будет скорее всего отправка каких-то писем по электронной почте с ящика одного конкретного человека на ящик другого конкретного человека, и жить все это будет до тех пор, пока один из этих конкретных людей не заболеет или не уйдет в отпуск. Безусловно, не все так плохо, некоторые из каналов взаимодействия между отдельными парами ведомств, особенно нужные и важные, давно уже автоматизированы и пристойно функционируют, но ни о какой единой, расширяемой системе речи идти не может. 
2. Соответственно, остаются все проблемы форматов, возможности автоматической обработки, доверия к электронной подписи (хотя фиг с ней, с электронной подписью - для тех вопросов, о которых идет речь при предоставлении электронных муниципальных услуг, в 99% случаев вполне достаточно будет доверять справке просто потому, что она пришла вроде как с известного адреса и выглядит "как обычно"). 
3. И еще появляются вопросы, например, персональных данных: а почему это паспортный стол или БТИ будет предоставлять персональные данные Иванова Абрама Умар-оглы администрации муниципального образования "город Екатеринбург"? Вот самому гражданину Иванову А.У.-О. - всегда пожалуйста. И пусть он с ними дальше делает всё, что ему угодно: хоть в муниципалитет несет, хоть на заборе расклеивает. А муниципалитету... Где доверенность от Иванова? Где лицензии и сертификаты всякие? Договор где? И пошла-поехала... 
4. И мы еще не задали главный вопрос: а будут ли все эти ведомства рады и готовы информационному обмену с муниципалитетом? Сейчас у них есть их привычный бизнес-процесс, они выдают свои справки в четвертом окошечке, с 9.45 до 11.30 по средам и пятницам (третья среда месяца - профилактика, первая пятница - санитарный день), а тут на тебе: переучиваться, и начинать работать по запросам какого-то из комитетов городской администрации, формировать эти справки в электронном виде, отправлять их куда-то. А ведь ни паспортный стол, ни налоговая, ни ГИБДД администрации города Екатеринбурга не подчиняются. Они все - федеральные органы исполнительной власти, куда там местному самоуправлению! Конечно, какие-то справки нужны и от подчиненных или близких муниципалитету структур - ЕРЦ, управляющей компании или просто соседних комитетов и отделов администрации, но какая с этого радость, если только часть справок удастся получать в электронном виде, а со всеми остальными - непонятно? 
Короче говоря, нереалистичность модифицированного бизнес-процесса чуть менее очевидна, но по прошествии некоторого времени становится тоже понятной. Можно упахаться, перестроить все бизнес-процессы на стороне муниципалитета, начать принимать заявления без приложений... и оказаться не в состоянии собрать необходимую для процессинга этих заявлений информацию от сторонних ведомств. 

IV. ДОЛОЙ СПРАВКИ! 
Итак, мы убедились, что невозможно создать систему муниципальных электронных услуг, так или иначе моделирующую нынешний "бумажный" бизнес-процесс, ключевое место в котором отводится сбору и представлению разного рода справок. Значит ли это, что ничего нельзя сделать? Радикальная идея как раз и состоит в том, что можно - только для этого надо полностью перестроить бизнес-процесс, отказавшись от справок. (То, что у нас получится, тоже будет не очень-то реальным, но, как говаривал Шерлок Холмс, если отброшены все возможности, кроме одной, то она оказывается верной, какой бы маловероятной она ни казалась). 
Ключевая идея базируется на том факте, что основанием для получения услуги является, как правило, информация о самом заявителе, и, как правило, заявитель этой информацией владеет. Проблема только в ее подтверждении. В бумажном бизнес-процессе подтверждение и организуется с помощью справок, но в электронном бизнес-процессе возможны иные подходы. 
Выглядеть все должно так: заявитель заполняет на портале электронных услуг муниципалитета форму заявления, без каких-либо приложений, но максимально подробную. Он сам, своими руками, заносит туда всю ту информацию, которая обычно содержится в справках-приложениях. Нужны сведения о составе семьи? Пусть будут в форме такие поля, и он их заполняет. Сведения о доходах? Пусть заполняет. О квартплате? Пусть заполняет. Человек в 99% случаев сам знает, сколько граждан зарегистрировано у него в квартире, в каком районе он проживает, сколько квадратных метров составляет площадь его квартиры, какая у него зарплата. Если по каким-то причинам не знает - пусть узнает; эту проблему ему предстоит решать за рамками нашей системы электронных муниципальных услуг, это не предмет ведения нашей системы. (Если надо узнать метраж с точностью до десятых: ОК, на сайте ФРС или БТИ, кто там сейчас этим занимается, тоже когда-нибудь появится сервис "Предоставление выписок по учету жилфонда", а пока что можно по старинке туда сходить, и взять справку. Только предоставлять эту справку никуда не нужно! Таким образом, электронный процесс оказывается по крайней мере гарантировано не хуже бумажного).   
Итак, заявитель внёс всю-всю-всю информацию в заявление. Отметил крыжик "Я гарантирую достоверность и полноту предоставленной мной информации". И кнопочку "Отправить". Всё. 
Что теперь делает муниципальный портал? Он не запрашивает никаких справок, он только проверяет предоставленную заявителем информацию. Делается это путем рассылки во все инстанции (по числу справок, которые раньше пришлось бы собрать заявителю) однотипных формализованных запросов с данными, предоставленными заявителем, и предполагающих ответ "да" или "нет". Если в итоге этого процесса все данные подтверждены (на все запросы получен ответ "да") - услуга предоставляется. Если где-то зажегся красный свет - заявитель уведомляется об этом через портал электронных услуг с подробным описанием деталей. Исправляет, повторяет. (Здесь уместно еще раз сказать о том, что никакой особой новизны в этом нет. Так работает, например, бумажный процесс получения загранпаспорта: ты сообщаешь всё о себе, а УФМС проверяет - делает запросы в милицию, в ФСБ, куда-то там ещё. Новым для меня лично является понимание, что схема абсолютно универсальна, и ей можно накрыть всю предметную область предоставления электронных услуг - именно этим пониманием я и пытаюсь тут сбивчиво с вами поделиться). 

Эта базовая схема очень проста, и с первого взгляда может не получиться ухватить все заложенные в ней преимущества, а их, между тем, немало: 
1. Миграция на эту схему может быть постепенной. Она не требует революций, и может быть начата прямо сейчас.
Для каждой услуги составляется реестр ведомств, в которых надо верифицировать предоставленную заявителем информацию - собственно, этот реестр есть уже сейчас, он неявно присутствует в том перечне, который напечатан на листочке А4 и прикноплен к дверям кабинета. Очевидно, что на автоматическую верификацию эти ведомства будут переходить очень постепенно, и не все сразу перейдут. ОК, тем. что уже готов - будем посылать автоматический запрос; тем, кто не очень готов - будем писать по электронной почте. А тем, кто совсем-совсем никак - будем официальное письмо на бумаге слать, или звонить по телефону, например. От заявителя всё это скрыто, он видит только чёрный ящик, в котором постепенно, с разной скоростью, загораются красные и зеленые лампочки. По мере автоматизации разных ведомств (кого-то мэрия сможет принудить, кто-то сам автоматизируется) лампочки будут загораться все быстрее и быстрее, пока, в один прекрасный день, верификация заявлений не станет происходить в режиме онлайн. 

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

3. В большинстве случаев верификация может проводиться асинхронно. 
В мире, в котором мы живем, очень мало бывает необратимых операций. Собственно, только одна есть - перечисление денег с расчетного счета на расчетный счет. Если муниципальная услуга подразумевает такую операцию (например, выплата каких-нибудь пособий или компенсаций), то, конечно, нельзя к ней приступать, пока полностью не подтверждено наличие оснований для выплаты. Во всех остальных случаях можно работать асинхронно - начинать предоставлять услугу, параллельно занимаясь верификацией. Например, написали люди заявление на постановку в очередь в детский сад. Что должна сделать система? Да просто взять, и тут же их поставить. И паралелльно запустить все проверки. Если какая-то из них не пройдет - ну, вычеркнем из очереди (или уведомим, что вычеркнем, если заявитель не внесет какие-то уточнения), ничего страшного. Практика обязательно покажет, что 95% или 98% подаваемых чере систему заявлений будут содержать в себе верную информацию - люди обычно всё о себе знают, а врать, зная о том, что вся информация будет проверена - нет большого смысла. Такой подход (начать предоставлять услугу, а параллельно проверять наличие оснований) может пригодиться, например, в тех случаях, когда один из некритичных компонентов всей системы полностью отключается - какая-нибудь служба месяцами не подтверждает и не опровергает правильность данных, и, при определенных условиях, может быть принято решение продолжать и без этого подтверждения. Ну а в конце концов всё придет к полному онлайну, и это будет уже неважно. 

4. Всем ведомствам надо договориться только об одном протоколе обмена данными. 
Речь идет по сути о том, чтобы в каждом ведомстве появился маленький сервер, который умеет делать только одну вещь: получать запрос в виде набора полей (гражданин такой-то, данные такие-то) и отвечать "да" или "нет". (Муниципалитет - не исключение. Предоставление какой-нибудь услуги на уровне региона легко может потребовать предоставление какой-нибудь справки из мэрии, то есть подход-то, конечно, симметрично может быть применен не только к муниципальным электронным услугам, а вообще к любым). Тут всё равно много собак зарыто (в каких ситуациях достаточно просто сказать "да", а когда все-таки нужна ЭЦП; кто определяет формат полей и т.д.), но всё-таки задача становится много проще: речь идет всего об одном универсальном протоколе и одном типе запросов для всей задаче межведомственного информационного взаимодействия! Это выглядит подъемно, и решаемо. И, опять же, не требует революций: давайте в каждом ведомстве поднимем такой сервер, но пусть он пока не будет интегрирован с локальной информационной системой этого ведомства; не страшно! Никто же снаружи не знает, что происходит у нас внутри, что мы пока не умеем автоматически парсить и процессить запросы, а разбираем их руками и ответы "да" или "нет" формируем тоже руками; постепенно будем учиться всё большую долю запросов обрабатывать автоматически, и через некоторое время всё заработает онлайн, просто потому, что нам станет лениво заниматься ручной обработкой. 

5. Систему можно сделать нечувствительной к небольшим ошибкам. 
Я весь прошлый год проработал в одной фирме, и получал 1488 рублей в месяц, и честно написал об этом в моем заявлении, забыв, однако, указать, что в феврале написал статью в журнал, и получил гонорар в размере 666 рублей. Сейчас я подал заявление на субсидию по оплате услуг ЖКХ, потому что мои счета за квартиру - 6600 рублей за год! - гораздо больше, чем 22% моего совокупного дохода. Мои данные неверны: согласно заявления, мой годовой доход составил 17856 рублей, а в справке из налоговой было бы указано 18522 рубля. Конечно, и в этом случае я все равно сохраняю право на субсидию, но если система на основании моего заявления спросит в налоговой: "Верно ли, что доход Иванова А.У.-О. составил 17856 рублей", то она получит отрицательный ответ (я уж не говорю о копейках и ошибках округления!) - и загорится красный свет. Однако понятно, что очень легко сделать нашу воображаемую систему электронных муниципальных услуг нечувствительной к такого рода ошибкам, и, в этом смысле, гораздо более комфортной для заявителя. Системе достаточно всего лишь научиться спрашивать: "Верно ли, что доход Иванова А.У.-О. не превысил 30000 рублей?" - и положительного ответа на этот вопрос будет вполне достаточно, чтобы принять положительное решение. Или, например, работать с какой-то погрешность: "Верно ли, что площадь квартиры составляет 27.6 плюс-минус 0.5 квадратных метра?" - пример, когда это могло бы пригодиться, тоже нетрудно придумать.   

6. Придумайте сами. 
Чем больше думаю, тем больше нахожу преимуществ у предложенного подхода, но не хочу лишать вас интеллектуального удовольствия от их придумывания. Скажу только: они есть (как есть и недостатки)! Придумайте сами еще преимущества "электронных услуг без справок", и расскажите мне о них! 

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

P.S. Все вышеизложенное относится к одному типу муниципальных электронных услуг: когда гражданину, заявителю, что-то надо от муниципалитета. Есть еще второй тип услуг - когда конкретному гражданину ничего не надо, когда услуга предоставляется неопределенному кругу лиц. Здесь моя позиция остается неизменной, и она все шире подтверждается, кстати, мировой практикой: муниципалитет вообще не должен оказывать услуги такого рода, это всё может и должен делать бизнес. Задача муниципалитета - вывалить наружу свои информационные ресурсы - будь-то данные о движении транспорта или расписание приема в поликлиниках - в открытом, хорошо задокументированном формате. А на базе этих информационных ресурсов бизнес создаст нужные и полезные сервисы для конечного пользователя, и все будут счастливы. 
 
В завершении этого поста хочу сказать спасибо двум упомянутым в самом начале умным людям, которые помогли мне навести в голове порядок: это Марина Андрусь, председатель комитета стратегического планирования администрации Екатеринбурга, и Олег Кац - ведущий программист "СКБ Контур", и просто очень хороший и умный человек. Марина Олеговна не пожалела времени, пришла на августовскую встречу волонтеров по обсуждению проекта, и очень подробно рассказала об ограничениях реального мира, а с Олегом мы просто вдвоем сели, всё это обсудили, и всё стало ясно. Спасибо!  

Оставить комментарий

Популярные посты:

• Архив