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

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

В федеральном законе от 27 июля 2010 г. № 210-ФЗ “Об организации предоставления государственных и муниципальных услуг” возможность для заявителей представлять документы в электронном виде при получении услуги с использованием Единого портала государственных и муниципальных услуг предусмотрено было реализовать до 01.07.2012-го. Поэтому уже в тот момент в ходе предоставления услуг ведомства должны были как обмениваться информацией друг с другом, так и получать от заявителей документы в электронном виде.

Участники работы для Комитета государственных услуг города Москвы проанализировали 50 услуг и опубликовали результаты этого анализа. Он показал существование более 380 форм входных/выходных документов. И в каждой из них выделено от 10 до 100 реквизитов. Нельзя забывать, что в состав информационного пространства помимо Web-сервисов входят также справочники и классификаторы, которых в Москве выявлено около 170, и структура каждого из них включает 3—15 различных реквизитов (полей).

При анализе сервисов, задействованных в исполнении услуги, было выделено от двух до семи операций, а также до 15 входных и выходных параметров. На конец 2012 г. количество существовавших сервисов составляло больше 1200 (415 на федеральном и 827 на региональном уровнях), а при подключении 23 118 муниципальных образований Российской Федерации (по данным Госкомстата от 08.06.2012) счет пойдет на десятки и даже сотни тысяч.

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

Участники тотальной электронизации услуг для населения со стороны трех уровней власти, запущенной в целях реализации упомянутого выше федерального закона № 210-ФЗ, оказались не готовы к такому колоссальному объему разработок, выполняемых прямым программированием.

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

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

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

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

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

Отметим, что в Концепции нет определения термина “оптимизация”. Его неоднозначность подчеркивается в статье на эту тему в русской википедии: “Оптимизация — модификация системы для улучшения её эффективности. Система может быть одиночной компьютерной программой, набором компьютеров или даже целой сетью, такой как Интернет. Хотя целью оптимизации является получение оптимальной системы, истинно оптимальная система в процессе оптимизации достигается далеко не всегда. Оптимизированная система обычно является оптимальной только для одной задачи или группы пользователей: где-то может быть важнее уменьшение времени, требуемого программе для выполнения работы, даже ценой потребления большего объёма памяти; в приложениях, где важнее память, могут выбираться более медленные алгоритмы с меньшими запросами к памяти. Более того, зачастую не существует универсального решения (хорошо работающего во всех случаях), поэтому инженеры используют компромиссные (англ. tradeoff) решения для оптимизации только ключевых параметров. К тому же усилия, требуемые для достижения полностью оптимальной программы, которую невозможно дальше улучшить, практически всегда превышают выгоду, которая может быть от этого получена, поэтому, как правило, процесс оптимизации завершается до того, как достигается полная оптимальность. К счастью, в большинстве случаев даже при этом достигаются заметные улучшения. Оптимизация должна проводиться с осторожностью. Тони Хоар впервые произнёс, а Дональд Кнут впоследствии часто повторял известное высказывание: “Преждевременная оптимизация — это корень всех бед”. Очень важно иметь для начала озвученный алгоритм и работающий прототип”.

Заметим также, что в ЕС с самого начала работ по электронному правительству в странах-членах никто не заморачивался весьма сложной на 2005-й год проблемой межведомственного взаимодействия в случае коллективного предоставления услуг министерствами и ведомствами. Для ежегодного сравнения “продвинутости” стран в реализации электронных услуг (benchmarking), во-первых, было выбрано всего 20 самых ходовых услуг министерств и ведомств, предоставляемых соло (двенадцать для граждан и восемь для бизнеса), во-вторых, определено четыре уровня электронизации услуг, причем не все они требовали самого высокого (или самого глубокого, кому как нравится) 4-го уровня. Стали ежегодно проводить сопоставительный анализ достижений стран в этой сфере — социалистическое соревнование, так сказать. Сейчас принята новая стратегия бенчмаркинга на 2012—2015 гг..

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

Развитие электронного правительства в России в 2008—2015 гг.

В России стартовали с некоторым разрывом во времени и одновременно реализуются электронные правительства трех типов в виде (в скобках приводится год запуска в эксплуатацию первых компонентов или услуг соответствующего электронного правительства):

  1. сети многофункциональных центров предоставления услуг (МФЦ, 2008);
  2. единого портала предоставления государственных и муниципальных услуг (ЕПГУ, 2009), региональных порталов и порталов муниципалитетов (далее сеть ЕПГУ, 2009), связанных с системой межведомственного электронного взаимодействия (СМЭВ);
  3. системы открытого правительства (2011). Открытые государственные данные уже стали обязательным компонентом веб-сайтов органов государственного и муниципального управления РФ. Компоненты системы открытого правительства (открытый регион, открытое министерство и открытые государственные и муниципальные данные) непосредственно реализуются на государственных и муниципальных веб-сайтах, доступ к ним производится не через ЕПГУ, а напрямую через Интернет (см., например, сайт Минэкономразвития России). В принципе сейчас создается сайт, где в одном месте будут собраны все государственные открытые данные.

В октябре 2013 г. общественности была представлена для обсуждения упомянутая выше Концепция. В ней предлагается интегрировать электронные правительства перечисленных выше типов, в результате получится интегрированное электронное правительство России. В контексте же глобального развития нужно отметить, что весь мир говорит об умном правительстве (smart government), хотя IBM выражается политкорректнее, предлагая использовать термин “более умное правительство” (smarter government).

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

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

К сожалению, в отечественной специальной литературе практически не исследуются вопросы организационно-методического и нормативно-правового обеспечения совместной работы министерств и ведомств по предоставлению услуг конкретным гражданам или неопределенному их кругу. Англоязычное экспертное сообщество c начала текущего века посвятило этой теме много работ, в которых изучаются различные аспекты так называемого объединенного правительства (joint up government), правительства как целого (government as a whole) или правительства как совокупности сообществ по интересам (community of interests).

Таким образом, выстраивается следующая хронология развития электронного правительства России, устремленная в будущее (рис. 1). 

  1. 2008 г. — сеть МФЦ. 2.
  2. 2009 г. — ЕПГУ+СМЭВ. 3.
  3. 2011 г. — Открытое правительство (ОП). 4.
  4. 2013 г. — Интегрированное правительство (МФЦ+ЕПГУ+СМЭВ). 5.
  5. 2015+ — если все пойдет хорошо, риски создания умного (электронного) правительства России не реализуются и будет поставлена задача формирования умного электронного правительства, чтобы не выпасть из мировой обоймы таких правительств, — то будет умное правительство.

Перечисленные выше типы электронных правительств России назовем электронными правительствами России 1-го, 2-го, 3-го, 4-го и 5-го поколений.

Следует отметить, что в русскоязычной литературе электронные правительства всех отечественных поколений не получили специального названия, но в литературе англоязычной для, например, ЕПГУ+СМЭВ оно есть: “связанное сетью правительство” (connected government, по определению Cisco).

Электронное правительство России на перепутье

Перевод государственных услуг в электронный вид является одним из первоочередных направлений государственной программы “Информационное общество 2011—2020 гг.” и касается развития инфраструктуры электронного правительства Российской Федерации. Важно отметить, что имея приоритетный статус и значение, такая деятельность регламентируется значительным числом федеральных нормативно-правовых актов, и это — находка российского государства: ни в одной другой стране такого способа плотного государственного руководства созданием и развитием электронного правительства — вплоть до рассмотрения и утверждения его концепций, архитектур и дорожных карт — нет.

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

Структуризация проблемы

В мировой практике принята четырёхуровневая модель обеспечения интероперабельности в международном и внутристрановом межведомственном межуровневом и одноуровневом взаимодействии министерств и ведомств при предоставлении электронных услуг (сверху вниз):

  1. нормативно-правовой уровень;
  2. организационно-методический уровень;
  3. семантический уровень;
  4. технический уровень.

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

Риски нормативно-правового уровня.

  1. Большое число участников процесса разных уровней (федерального, регионального, муниципального) создает угрозу постоянного торможения процесса из-за различных проблем коммуникации. В число таких проблем входят: конфликты интересов; территориальная разрозненность участников; рассогласованность понятийного аппарата участников; технические проблемы коммуникации.
  2. Недостаточная степень вовлеченности экспертов, а также сотрудников органов исполнительной власти, обладающих практическим опытом оказания государственных услуг может привести к выработке административных регламентов, оторванных от реальности.
  3. Большой объем нормативно-правовой базы, регулирующий различные аспекты оказания государственных услуг, и недостаточное внимание к ее анализу могут привести к выработке решений, вполне приемлемых с технологической, но абсолютно недопустимых с правовой точки зрения.
  4. Изменения в наборе и функциях федеральных и региональных, а также муниципальных органов власти. Например, на сайте госуслуг “застревает” информация о министерствах и ведомствах, которые уже ликвидированы решениями правительства или президента. И нет никакой информации, кому переданы функции по предоставлению услуг ликвидированного министерства или ведомства и переданы ли они вообще.
  5. Изменения в нормативно-правовых актах (НПА), непосредственно касающихся параметров услуг. Например, изменение возраста выхода на пенсию по старости может повлечь лавину изменений в других НПА и в услугах, которые используют этот параметр.

Риски организационно-методического уровня.

  1. Отсутствие единой методологии разработки административных регламентов оказания государственных услуг, полноценно учитывающей требования автоматизации, на уровне субъектов Российской Федерации приводит к невозможности внедрения, распространения и тиражирования готовых решений на муниципальном уровне.
  2. Отсутствие типового, настраиваемого в соответствии с единой методологией инструмента оказания государственных услуг в органах государственной власти и органах местного самоуправления делает фактически невозможной реализацию федерального закона № 210-ФЗ на муниципальном уровне, что, безусловно, не позволит обеспечить возможность качественного и своевременного оказания государственных услуг в электронном виде.

Риски семантического уровня.

  1. Гетерогенный и распределенный характер технологической платформы исполнения государственных услуг ведет к чрезмерному усложнению процесса проектирования и реализации. Так, например, обычная операция по передаче данных о заявителе между ФОИВ (федеральный орган исполнительной власти) и РОИВ (региональный орган исполнительной власти) в рамках полноценной системы исполнения государственных услуг требует взаимодействия от трёх до десяти информационных систем. При этом каждая система имеет своё лингвистическое обеспечение, использует свою модель данных, поддерживает собственные протоколы передачи данных, обладает определённой степенью автоматизации и т. д.
  2. Отсутствие четкого стандартизированного процесса подготовки государственных услуг к переводу в электронный вид в лучшем случае ведет к неэффективному расходованию ресурсов, а в худшем — к срыву всего процесса перевода.
  3. Отсутствие средств контроля над ходом подготовки услуг к переводу в электронный вид может привести к систематическим нарушениям графика перевода и неверным оценкам степени готовности услуг к оказанию в электронном виде.

Риски технического уровня.

  1. Неготовность ИКТ-инфраструктуры регионов и муниципалитетов к развертыванию системы предоставления услуг в электронном виде, включая подключение к СМЭВ и использование решений по информационной безопасности (ИБ) и охране персональных данных. Другими словами — высокий порог подключения региональных и особенно муниципальных информационных (зачастую унаследованных) систем к СМЭВ и сложность реализации требований к ИБ и охране персональных данных.
  2. Отсутствие в регионах и муниципалитетах кадров для разработки и сопровождения электронных услуг.
  3. Отсутствие опыта использования разделяемых внутренних и внешних услуг и соответствующего НПА для организации коллективной работы министерств и ведомств над одной проблемой.

По каждому виду обеспечения интероперабельности имеется много документов:

  • по нормативно-правовому обеспечению системы в целом есть список в Концепции, но значительно более широкие реестры НПА содержатся на сайтах регионов, потому что значительная часть процесса перевода регулируется именно на региональном уровне. Перечень нормативно-справочной документации о СМЭВ есть на ЕПГУ;
  • организационно-методические материалы размещены на Портале методической поддержки реализации федерального закона № 210-ФЗ “Об организации предоставления государственных и муниципальных услуг”;
  • к сожалению, понятие “ семантической интеграции министерств и ведомств при совместном предоставлении министерствами и ведомствами электронных услуг” вообще отсутствует в лексиконе участников и субподрядчиков проектов разработки и сопровождения услуг, предоставляемых в электронном виде;
  • система документов по технической платформе для исполнения функций системы предоставления услуг в открытом доступе отсутствует, отдельные документы есть на региональных сайтах, например, на сайте кемеровского региона.

В различных местах Концепции есть лишь “хотелки” по совершенствованию (оптимизации) административных регламентов обеспечения перевода услуг в электронный вид. Но требования к переводу не обозначены.

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

К середине 2013 г. отставание в реализации масштабного плана перевода федеральных, региональных и муниципальных услуг на электронные рельсы на платформе ЕПГУ+СМЭВ стало хроническим и нарастало; в результате эта проблема была специально рассмотрена на заседании Правительственной комиссии по внедрению информационных технологий в органах власти. Председатель комиссии Д. Медведев высказал на заседании мнение, что перевод услуг в электронный вид можно ускорить за счет решения следующих задач.

  1. Формирование единой общефедеральной структуры оказания услуг, включающей как онлайновые, так и офлайновые сервисы. Под этой структурой подразумевается не только единый портал государственных услуг, на котором сегодня зарегистрировано более 4 млн. граждан, но и сеть многофункциональных центров. На момент проведения заседания было создано около 700 центров, к 2015 г. откроется около 3 тыс. Ещё один элемент — это филиальная сеть “Почты России”, естественно, при условии модернизации самих отделений, а их более 40 тыс., и обучение соответствующего персонала, чтобы он был готов к этой работе,
  2. Четкое определение понятия “предоставление услуги в электронном виде”. За ним должна стоять не веб-страница соответствующего ведомства, а “нормальный, современный, полноценный интерфейс, который упростил бы общение с чиновниками”. Интерфейс должен быть понятным не только “продвинутым” пользователям, но и обычным людям, в том числе пожилым, которые, тем не менее, пытаются осваивать электронные услуги.
  3. Создание системы, позволяющей получать государственные и муниципальные услуги на всей территории страны независимо от места жительства или пребывания.

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

На первом заседании переименованной Правительственной комиссии Минкомсвязи и Минэкономразвития — после обсуждения ситуации с торможением развития системы предоставления электронных услуг — был сделан вывод о том, что необходимо разработать, согласовать и утвердить “Концепцию развития механизмов предоставления государственных и муниципальных услуг в электронном виде” (протокол № 1 п. 4 р. 1 от 19.09.2013). Проект Концепции 16 октября 2013 г. был представлен общественности для обсуждения на сайте Минкомсвязи.

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

Концепция: анализ и комментарии

Кратко рассмотрим содержание Концепции. Она, во-первых, фиксирует текущее состояние электронного правительства в Российской Федерации с точки зрения перевода услуг в электронную форму, управления формированием электронного правительства и развития его инфраструктуры. Причем фиксирует в бюрократическом стиле, используемом госслужащими при освещении своих успехов. (Весь документ создает впечатление у тех, кто не следит постоянно за развитием электронного правительства России, что работа проделана огромная, в целом всё неплохо, нужно только кое-что оптимизировать — и все будет в полном порядке!) И во-вторых, вопросы, которые выше были отнесены к различным уровням обеспечения интероперабельности, в этой Концепции, к сожалению, в явном виде не обозначены и иногда рассматриваются независимо от компонентов электронного правительства, а иногда в контексте того или иного компонента (инфраструктуры, например), так что неясно, все ли компоненты системы, реализующей предоставление услуг, охвачены и все ли виды обеспечения всего жизненного цикла электронной услуги предлагается оптимизировать.

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

Нигде не учитывается, что государственная услуга — это процесс, а значит, недостаточно построить модель данных, в которой учтены только объекты, даже с возможностью построения иерархии и наследования, как представлено в разделах про нормативно-справочную информацию (НСИ) и базисные государственные информационные регистры (БГИР).

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

При этом никак не определены пути получения данных, то есть ни объекты БГИР, ни формы документов, ни собственно Федеральный реестр государственных и муниципальных услуг (ФРГУ) не имеют связи с конкретными входными/выходными параметрами и операциями конкретных федеральных, региональных и муниципальных сервисов, которые отвечают за предоставление конкретных данных. Это означает, что невозможно гарантировать автоматизированное получение сведений, которые заложены в уже спроектированную и утвержденную электронную форму документа, то есть невозможно спроектировать действительно исполняемый в системе процессинга регламент государственной услуги.

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

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

Муниципальный уровень, несмотря на предлагаемые принципы экстерриториальности предоставления государственных услуг, снова остался слабо проработанным. Между тем построение единой системы передачи данных (ЕСПД) не станет панацеей в решении проблемы получения сведений, которые ведутся и учитываются не в центральных (федеральных или региональных) системах, а непосредственно на местах.

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

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

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

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

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

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

Что говорит передовой мировой опыт

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

Сервисно-ориентированная архитектура электронного правительства

К сожалению, чиновные участники работ по созданию в России электронного правительства и системы электронных услуг для него (а с 2002-го до нынешнего года их сменилось три поколения — назовем их условно поколениями Реймана, Щеголева, Никифорова) не изучали мировой опыт, а те материалы, которые им представляли эксперты как отчеты по НИР в рамках ФЦП “Электронная Россия 2002—2010 гг.”, освещавшие Федеральную архитектуру предприятия США (Federal Enterprise Architecture, FEA, см. статью и ее продолжение) и предлагавшие рекомендации по ее внедрению в России, они просто клали на полку.

О чем архитектура FEA? Если грубо и коротко, то:

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

Обратимся ко второму пункту. Еще в 2002 г. в составе FEA была опубликована “Справочная модель бизнеса [деятельности]” федерального предприятия, где представлена классификация функций правительства США. Эта модель позволяет решать вопрос, который совершенно не учитывается разработчиками наших перечней функций правительства, — слияние/разделение и уничтожение/создание министерств и ведомств.

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

В 2002 г., почти одновременно с самой архитектурой FEA, появилась “Сервисная и компонентная архитектура” (Services and Components Based Architectures, SCBA), которая стала стратегическим руководством по реализации распределенных и повторно используемых сервисов и компонентов, а затем, в 2008-м, было опубликовано “Практическое руководство по федеральной сервисно-ориентированной архитектуре”. Эта архитектура приводит грануляцию функций правительства в соответствие их программной реализации в информационных системах (рис. 2). В публикации представлена таблица, где приведены технологии, которые упомянуты в этой архитектуре.

В архитектуре SOA есть динамически порождаемые сети сервисов и процессов (языки для хореографии веб-сервисов BPEL4WS, WSCI), а также средства отражения семантики предметной области (XML Schemas, OWL, NIEM). Чего в ней нет, так это средств отражения поведения и ролей субъектов предметной области (функций или услуг электронного правительства).

Интересно, что такой архитектурный подход реализован еще в 2010 г. отечественными специалистами; он дополнен возможностями задания поведения и ролей субъектов предметной области. До этого в 2008 г. была опубликована работа на эту тему сотрудников Института ООН в Макао.

Семантическая интеграция министерств и ведомств

Термин “обмен информацией” или “совместное использование информации” стал широко применяться после разрушения террористами башен-близнецов Всемирного торгового центра в Нью-Йорке 11 сентября 2001 г. Президент Буш создал специальную федеральную комиссию “9/11”, которая заслушала многих чиновников разного уровня власти, проанализировала соответствующую информацию и составила доклад, уелью которого было выявить причины отсутствия реакции силовых министерств и ведомств правительства США на известную им информацию о планируемой террористической атаке и каких-либо действий по ее предотвращению.

После публикации отчета комиссии “9/11” Буш издал несколько распоряжений, обязывающих уполномоченные силовые ведомства руководствоваться политикой “делиться друг с другом известной им информацией”, т. е. снять межведомственные информационные барьеры. В результате была создана государственная модель обмена информацией (National Information Exchange Model, NIEM, рис. 3), ставшая одной из лучших мировых практик построения информационного взаимодействия с большим количеством объектов обмена и его участников. Фактически NIEM — это стандарт межведомственного обмена информацией в США, созданный на базе референсной (эталонной) модели GJXDM (Global Justice XML Data Model) и распространенный на множество других предметных областей.

Модель позволила интегрировать силовые ведомства США (которых порядка одиннадцати) в борьбе с внутренним и внешним терроризмом. Кроме того, был инициирован проект по созданию так называемой Государственной среды совместного использования информации (Information Sharing Environment, ISE), во главе которого поставлен специальный чиновник федерального уровня (программный менеджер ISE). Ему поручили контроль над реализацией положений закона 2004 г. о реформе разведки и предотвращении терроризма, в котором отражены и рекомендации Целевой группы по национальной безопасности в информационном веке.

Термин “совместное использование информации” в лексиконе информационных технологий имеет долгую историю. Первоначально он означал однонаправленную передачу данных от отправителя к получателю. Такая передача регламентируется десятками открытых и проприетарных протоколов. Например, протокол электронного обмена данными (electronic data interchange, EDI) является успешной реализацией обмена коммерческими данными, был специфицирован в конце 1970-х и используется до сих пор.

Относительно недавние инициативы по стандартизации протоколов обмена информацией включают расширяемый язык разметки (XML), простой протокол доступа к объектам (Simple Object Access Protocol, SOAP) и язык описания веб-сервисов (Web Services Description Language, WSDL).

Пространство развития стандартов семантического веба и семантических веб-сервисов в координатах “статика/динамика” и “сегодня/завтра” показано на рис. 4.

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

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

Заключение

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

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

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

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

Таким образом, для успешного перевода государственных услуг в электронный вид требуется целостная конструкция, в которой на базе бесшовной технологии будет организован связный процесс подготовки и оказания государственных услуг, а также выстроено единое информационное пространство на основе единой модели данных для всех уровней информационного взаимодействия (рис. 5).

Необходимые условия для решения проблем подготовки госуслуг:

  • организация единого, комплексного подхода к процессу подготовки госуслуг, с учетом всех составных компонентов, на необходимом и достаточном уровне структуризации и формализации самой услуги;
  • применение при подготовке услуг к переводу в электронный вид промышленных технологий с использованием языков программирования, которые подразумевают манипуляции с объектами моделей данных, автоматическую интерпретацию метаданных;
  • обеспечение коллективной работы большого количества участников в рамках семантического, нормативно-правового и организационно-методического пространства для реализации полноценного взаимодействия.

Автор статьи — к. ф.-м. н., председатель правления АНО “Центр компетенции по электронному правительству”.