В круглом столе принимают участие
Юрий АКАТКИН, директор ФГУП КБПМ
Максим БАРСУКОВ, директор Департамента информационных систем, АМТ-ГРУП
Андрей БУРИН, руководитель департамента по работе с госсектором, компания ФОРС
Геннадий КОПАЕВ, руководитель направления по работе с органами государственной власти, КСК
В декабре прошлого года Правительством РФ была утверждена «Концепция развития механизмов предоставления государственных и муниципальных услуг в электронном виде». Как вы оцениваете этот документ в контексте принятых ранее? Насколько в целом сформировано российское законодательство в области предоставления электронных услуг населению? Каких документов, на ваш взгляд, не хватает?
Юрий АКАТКИН
Системных документов подобного рода было немного, однако каждый из них соответствовал уровню развития на конкретный период и не «смотрел в будущее». Например, в «Системном проекте формирования в Российской Федерации электронного правительства» устройство системы межведомственного электронного взаимодействия (СМЭВ) упоминалось вскользь, а некоторые вопросы в принципе не могли быть учтены. В этом плане Концепция, впитавшая опыт нескольких лет эксплуатации и значительных модернизаций систем и сервисов, включая саму СМЭВ, является в какой-то степени шагом вперед. Но и она не соответствует современным мировым представлениям о принципах предоставления электронных государственных и муниципальных услуг, в которых акцент ставится на проактивности – динамическом формировании услуги для гражданина на основе сведений о нем, в том числе полученных в рамках межведомственного запроса. С другой стороны, все существующие документы носят разрозненный и бессистемный характер, в том числе в связи с тем, что разрабатываются в интересах различных ведомств. Поэтому единая, целостная методология не формируется, что является одной из причин той тупиковой ситуации, которая сложилась в данной сфере.
Андрей БУРИН
Такую Концепцию следовало принять уже давно – два-три года назад, когда стартовали первые реальные проекты по переходу к электронному правительству на федеральном и региональном уровнях. Еще тогда нужно было законодательно закрепить все то, к чему пришли столь долгим путем проб и ошибок.
Но сейчас нормативно-правовое поле, регулирующее порядок предоставления госуслуг, в основном уже сформировано, и этот процесс продолжается. К примеру, хоть и медленно, но все же решаются вопросы унификации госуслуг, а в самое ближайшее время ожидается принятие новых методических рекомендаций, регламентирующих технические вопросы межведомственного электронного взаимодействия.
Затрудняет движение вперед отсутствие продуманной стратегии, которая опиралась бы на российские реалии и зарубежный опыт, четко ставила конечные цели и законодательно закрепляла конкретные шаги и средства решения намеченных задач. До сих пор есть проблемы с единым реестром госуслуг, от региона к региону разнятся их наименования и регламенты исполнения, причем это касается даже первоочередных услуг. Должен существовать единый утвержденный формат взаимодействия на уровне «регион – оператор», некий стандарт организационно-правовых отношений между ними.
Геннадий КОПАЕВ
Документ зафиксировал практически все назревшие проблемы и является отличной основой для «разбора завалов». Пожалуй, это самый нужный документ за последние годы. Направления развития я постарался осветить в статье «Перевод госуслуг в электронный вид: проблематика, направления развития». Срочно нужны документы, описывающие архитектуру электронного правительства, поскольку сейчас различные инициативы выглядят несбалансированными, иногда противоречивыми. Требуются как описание общефедеральной архитектуры, так и подходы к региональной ИТ-инфраструктуре. При этом электронные услуги и СМЭВ – только часть инфраструктуры.
Еще один тип недостающих документов – финансово-экономическое обоснование работ. Сейчас решения принимаются «на глазок», какова цена вносимых изменений (например, СМЭВ 3.0) не известно. Непонимание архитектуры и стоимости работ в целом приводит к значительным искажениям, бесконечному перерасходу средств и отсутствию значимого результата.
Эксперты отмечают отсутствие единого инструментария для потоковой разработки и поддержки услуг в электронном виде, что приводит, в частности, к проблемам межведомственного взаимодействия. Считаете ли вы данный момент принципиальной проблемой предоставления госуслуг в электронном виде? Какова в перспективе вероятность появления единой технологической платформы для электронизации госуслуг?
Юрий АКАТКИН
К сожалению, применяемые сегодня решения в принципе не учитывают возможность массового перевода государственных и муниципальных услуг в электронный вид, тем более с учетом управления изменениями, что особенно важно в рамках постоянного обновления законодательства. Предлагаемые подходы приводят не к построению научно обоснованной методологии, а к сокращению перечня государственных услуг. Очевидно, что необходимо на базе современных принципов организации обмена информацией (information sharing), промышленных платформенных решений и уже апробированных технологий выстроить целостную систему, в которой будет обеспечена коллективная работа широкого круга экспертов в рамках единого информационного пространства на всех его уровнях – семантическом, нормативно-правовом и организационно-методическом. В такой конструкции специалистам различных предметных областей предоставляется единый инструментарий как для разработки государственных услуг, автоматизированной настройки сервисов для обеспечения межведомственного взаимодействия, так и для оказания государственных услуг на основе исполняемых регламентов в формате, например, BPMN.
Такие технологии и инструменты безусловно существуют, подходы давно описаны. Существуют не только международные стандарты, но и перспективные российские разработки, так что перспектива у единой технологической платформы несомненно есть, осталось дождаться политической воли.
Максим БАРСУКОВ
По моему мнению, постановка на поток разработки услуг в электронном виде и создание единой технологической платформы для электронизации госуслуг – несколько утопичная задача. Мы периодически слышим о разных глобальных универсальных проектах, как в нашей стране, так и за рубежом, но все они не оправдывают ожиданий в полной мере. В жертву универсальности приносятся интерфейсы, usability и даже сами процессы.
У межведомственного взаимодействия, как и у самих ведомств, действительно есть проблемы, правда, в они большей степени коренятся в неправильном подходе к автоматизации деятельности. Сейчас процесс строится от потребителя госуслуги: определяется госуслуга, вставляется в план, отдается на реализацию подрядчику. Подрядчик анализирует способ предоставления услуги и с минимальными изменениями пытается автоматизировать имеющийся, не идеальный с точки зрения информатизации, процесс. Получается автоматизация ради автоматизации, нарушается сам ее порядок. В действительности же ведомства могут быть не готовы. Сначала необходимо провести анализ, систематизировать и выстроить процессы как внутри ведомств, так и межведомственного взаимодействия, провести комплексную автоматизацию и уже на подготовленной почве внедрять госуслуги.
Говоря о единых платформах и потоковой разработке, нужно иметь в виду разные факторы. Например, финансовый – Москва может себе позволить строить решения на дорогостоящих платформах, а регионы чаще прибегают к Open Source-решениям. Если взять нынешний уровень автоматизации, то в регионах, понятно, он и ниже, и качеством хуже. Необходимо выработать единые подходы, некие рамки – в результате могут появиться несколько однотипных решений, из которых на основе опыта эксплуатации следует выделить ограниченное число лучших (best practice). Данные решения должны быть доступны для тиражирования. В перспективе это приведет к значительной экономии бюджетных денег и сроков внедрения.
Неким стопором выступает и имеющееся разнообразие уже внедренных в органах власти систем и технологий, иногда построенных на базе кустарных разработок, иногда работающих без сопровождения производителя (которого может уже и не существовать). Здесь важно провести скрупулезный анализ, выделить лучшие решения и включить их в перечень типовых решений.
Очень важной задачей является достижение большей открытости и унификации форматов обмена данными между участниками взаимодействия. Это требует значительной аналитической работы и распространения ее результатов на всех участников с безусловным учетом их интересов. Дополнительным стимулом для этого может стать открытие исходных кодов и части проектной документации для всеобщего использования. Ярким примером успешности такого подхода может служить портал государственных услуг в Великобритании (gov.uk). Открытость дает много плюсов: автоматически увеличиваются требования к качеству реализации, выделяются проблемные точки, во главу угла ставится возможность повторного использования кодов (модулей, программ), на рынке труда легче найти необходимых специалистов и т. д. Потоковую разработку я вижу именно в такой реализации, когда «поток» формируется из накопленных знаний и подпитывается готовыми кадровыми ресурсами.
Андрей БУРИН
Похожий инструмент потоковой разработки и поддержки услуг в электронном виде уже несколько лет пытается создать «Ростелеком» на базе своего решения. Далеко не все субъекты федерации захотели или смогли с ним работать, а результативность такого подхода в отношении федеральных органов власти вообще внушает большие сомнения, учитывая их многолетние самостоятельные вложения в развитие ведомственных ИТ. Мы убеждены, что экономически такой подход неэффективен. Поэтому, на наш взгляд, оптимальный вариант – развитие в сторону SOA.
Вместе с тем, в процессе перевода госуслуг в электронный вид задействован целый ряд информационных систем, таких как СМЭВ, РПГУ и/или ЕПГУ, ведомственные информационные системы или типовые информационные системы (системы исполнения регламентов). Для некоторых из них создание потокового инструмента – это реальность, которую, например, ФОРС воплотил в жизнь еще два года назад, создав для одного из своих заказчиков подсистему конструктора форм в рамках регионального портала госуслуг. Эта подсистема является инструментом администратора, позволяющим ему в потоковом режиме настраивать экранные формы портала, встраивать необходимые элементы управления и т. д. Такой принцип гибкой настройки приложений, не требующий внесения корректив в исходный код программ, мы постарались максимально использовать и в других подсистемах нашего комплексного решения для создания региональных компонентов «электронного правительства».
Геннадий КОПАЕВ
Абстрактно идея использования единого инструментария экономически целесообразна. Но практика построения «электронного правительства» показывает, что его части, отданные на откуп одному поставщику, реализуются не оптимально. Создание конкурирующих систем приводит к соревнованию разработчиков и появлению качественных продуктов. Например, в части межведомственного взаимодействия существуют три-четыре неплохих решения. Усложнение требований к компонентам «электронного правительства», например переход к СМЭВ 3.0, уменьшит количество создателей «поделок». То есть произойдет здоровая переструктуризация, уменьшение количества разработок.
Еще одна важная проблема, отмечаемая экспертами, – поддержка реестра госуслуг в актуальном виде в связи с постоянным обновлением законодательства. Как, на ваш взгляд, можно ее решить?
Юрий АКАТКИН
Вообще, проблема поддержки реестра государственных услуг, а также важность создания других самостоятельных реестров (например, реестра форм документов) при организации единой целостной системы подготовки государственных услуг станет в принципе неактуальной. Реестры станут всего лишь формой «хранения» сведений, необходимых для выделения элементов информационного обмена, увязанных с требованиями нормативно-правовых актов, на основе которых строится единая модель данных.
Максим БАРСУКОВ
Решение проблемы актуальности реестра госуслуг может быть только комплексным. Во-первых, должны быть внесены изменения в общий порядок вступления законов в силу, где необходимо на законодательном уровне прописать обязательность заблаговременной публикации изменений в реестре госуслуг. Либо должно быть расширено понятие «официальное опубликование», куда должна быть включена обязательная публикация в реестре. Во-вторых, информационные системы, обеспечивающие функционирование реестра госуслуг, должны поддерживать механизмы публикации госуслуг до их вступления в силу с гарантированным автоматическим обновлением в требуемое время. Наконец, для того чтобы механизм своевременной публикации госуслуг заработал, необходимо проработать регламенты обращения к оператору реестра госуслуг, определить сроки обработки обращения, способы подтверждения фактического размещения обновления в реестре госуслуг. Только при таком подходе, когда изменения законодательства не смогут проходить без предварительной публикации в реестре, будет наведен порядок в данной сфере.
Андрей БУРИН
В принципе, стоило бы остановить внесение изменений в законодательство, но, как мы понимаем, нельзя требовать невозможного. Вместе с тем, конечно же, нужен гибкий инструмент, позволяющий вести в реестре подробное и, главное, максимально формализованное описание регламента исполнения государственных и муниципальных услуг (с использованием при описании развитой системы классификаторов и справочников, ролевой модели работы с системой специализированных групп пользователей). Такой инструмент позволит всегда поддерживать реестр в актуальном состоянии, сколь бы часто и какие бы изменения ни вносились в законодательную базу. Такую услугу мы тоже предоставляем.
Геннадий КОПАЕВ
Единственный вариант решения – наличие документированной возможности выгрузки сведений в ФРГУ. Многолетние попытки актуализации реестра силами одного поставщика показывают удручающие результаты.
Какие три технические/методические проблемы предоставления электронных услуг вы назвали бы основными?
Юрий АКАТКИН
К основным проблемам можно отнести следующие:
1) путаница в управлении. Изначально смешиваются функции заказчика и исполнителя, по сути, созданием системы занимается сам заказчик, в том числе выводя, например, обсуждение концепций на правительственный уровень. Другой пример – Консультативный совет по вопросам развития и эксплуатации инфраструктуры электронного правительства при Министерстве связи и массовых коммуникаций Российской Федерации, в котором даже председатель (он же главный конструктор ИЭП) назначается из числа государственных гражданских служащих министерства в должности не ниже директора департамента Минкомсвязи, т. е. является чиновником – представителем заказчика;
2) отсутствие семантического уровня интеграции при межведомственном взаимодействии и оказании государственных услуг. Минкомсвязи отвечает за инфраструктуру, каналы связи, разработку информационных систем, Минэкономразвития – за реализацию административной реформы в целом, а между ними – разрыв. Нет единой методологии, нет целостности, и, как следствие, возникает лишь набор разрозненных решений (технического, нормативного или инфраструктурного уровня) и не связанных между собой концепций. При этом результата, как мы видим, нет;
3) невозможность управления изменениями. Это проблема, о которой достаточно часто говорят, много пишут в концепциях, но не могут решить. Оказание государственных услуг – гибкий процесс, связанный с множеством нормативно-правовых и законодательных актов. Контролировать изменения и поддерживать устойчивость системы невозможно вручную, без организации целостного, связного цикла подготовки государственных услуг, в котором все элементы информационного обмена будут увязаны не только между собой, но и с требованиями нормативно-правовых актов.
Максим БАРСУКОВ
Частично я затронул технические/методические проблемы предоставления госуслуг в ответе на второй вопрос – говоря о подходе «от потребителя» и о неготовности ведомств и некоторых органов власти к сопровождению предлагаемой модели оказания электронных государственных услуг. Фактически до сих пор не решены вопросы автоматизации многих основных рабочих процессов самих органов власти, в том числе непосредственно связанных с оказанием государственных услуг. Во многих ведомствах, особенно на региональном уровне, не хватает грамотных специалистов, которые могли бы обеспечить подготовку и функционирование тех или иных сервисов. Недостаточная грамотность и невнимательность зачастую приводят к несоблюдению исполнителями и органами власти уже принятых регламентов взаимодействия и публикации новых сервисов, что автоматически обусловливает многократное увеличение сроков ввода электронных услуг в эксплуатацию.
Еще один важный аспект – искусственные ограничения на использования ФСМЭВ и РСМЭВ. На текущий момент главная задача этих систем – безопасный транспорт данных. Оператор СМЭВ всячески открещивается от оркестровки сложных госуслуг (т. е. услуг, в предоставлении которых участвуют несколько ведомств) на уровне СМЭВ, потому что не хочет брать на себя ответственность за их предоставление. В результате «бизнес-модель» предоставления услуги усложняется как с точки зрения ее внедрения, так и с точки зрения прозрачности. К тому же снижается качество предоставления услуги, а именно удлиняются сроки, поскольку ведомства обрабатывают заявку последовательно, а не параллельно.
Если говорить о внешней стороне медали – портале госуслуг, то в погоне за количеством и сроками проявляются проблемы usability, а именно проблемы быстрого доступа к необходимой услуге, удобного интерфейса и адекватной обратной связи как по ходу оказания услуги, так и по результатам.
Андрей БУРИН
Первая проблема – недостаточная унификация или типизация регламентов оказания услуг на региональном и муниципальных уровнях (наличие большого количества схожих по регламентам услуг), а также до сих пор не решенный вопрос единой системы НСИ.
Вторая – неполное соблюдение целым рядом федеральных ведомств технических требований, приведенных в Методических рекомендациях по организации межведомственного электронного взаимодействия.
Третья – отсутствие прозрачного для всех субъектов механизма вывода государственных услуг на ЕПГУ, а также отсутствие на сегодняшний день возможности полной интеграции личных кабинетов на РПГУ и ЕПГУ.
Геннадий КОПАЕВ
Основная проблема электронных услуг на сегодняшний день – это фактическое их отсутствие с юридической точки зрения. Кстати, этот момент зафиксирован в Концепции.
Решение таких задач государственного масштаба, как предоставление электронных госуслуг, очевидно невозможно без использования современных ИТ-продуктов и привлечения системных интеграторов. Конкуренция на ИТ-рынке как между продуктами, так и между компаниями высока и будет только возрастать. Как должен выглядеть, на ваш взгляд, цивилизованный подход к привлечению поставщиков ИТ-решений органами федеральной и региональной власти?
Юрий АКАТКИН
На сегодняшний день конкуренция происходит между крупными системными интеграторами федерального или регионального уровня, которые зачастую предлагают собственные типовые решения и используют прибыльный способ реализации – ручное программирование (а затем перепрограммирование). Таким образом, очевидна крайне низкая заинтересованность в анализе и применении международного опыта, в проведении подлинной научно-исследовательской работы, массовом привлечении высших учебных заведений и построении экспертного сообщества профессионалов в сфере information sharing. Целесообразно было бы идти путем создания единого центра подготовки государственных услуг, в рамках которого будет обеспечиваться создание и распространение общедоступных открытых стандартов информационного обмена, качественного инструментария для разработчиков, научно обоснованных современных методик. Тогда будет открыт путь перспективным разработкам и разработчикам, от студентов и малых предприятий до крупного бизнеса, что означает честную конкуренцию, прозрачность критериев оценки качества.
Максим БАРСУКОВ
Основными принципами, на которых может строиться работа над столь важным проектом, как электронные государственные услуги, являются открытость и конкуренция именно решений, а не компаний. Распространение решений, доступность их исходных кодов позволила бы максимально быстро распространять накопленный опыт и привлекать больше компаний-интеграторов для развития систем. Практика, когда все работы отдаются одному исполнителю, на мой взгляд, в современных реалиях не оправдывает себя. Единый исполнитель, получив громадный пласт работ, сосредотачивается на наиболее важных, приоритетных для заказчика задачах, остальные работы выполняются в фоновом режиме, часто с большой потерей качества. Выход из такой ситуации – дробление работ и привлечение большего числа исполнителей.
Важно также понимать, что если ориентироваться на конечного потребителя услуг, то при реализации проектов, рассчитанных на массовую интернет-аудиторию, необходимо привлечение зарекомендовавших себя интернет-компаний. Российский системный интегратор отстает от тенденций развития пользовательских интерфейсов в Интернете, имеет мало опыта работы с интернет-аудиторией, продвижения услуг. Это является дополнительным препятствием при создании и популяризации электронных государственных услуг среди пользователей Сети.
Для создания более развитой конкурентной среды в сфере предоставления госуслуг гражданам, возможно, некоторые услуги следует предоставлять не только на портале госуслуг – можно создавать отдельные сайты и приложения (например, для планшетов), адаптированные под конкретную услугу. Лучше всего создать такие условия, когда каждый желающий сможет написать свое приложение, предоставляющее госуслугу, а выживут сильнейшие, действительно лучшие решения. Таким образом мы уйдем от концепции универсального громоздкого портала с большим объемом данных в сторону специализированных мини-приложений, по функциональности максимально удовлетворяющих пользователей и создаваемых в здоровой конкурентной среде. Понятно, что данная концепция не отменяет необходимости единого портала госуслуг.
Андрей БУРИН
К сожалению, у заказчиков государственного сектора любой цивилизованный подход к привлечению поставщиков сводится к необходимости строжайшего соблюдения соответствующего законодательства, которое с нового 2014 г. серьезно изменилось в связи с вступлением в силу нового Федерального закона № 44-ФЗ о государственной контрактной системе. Особенности применения данного ФЗ нам еще предстоит обсуждать. Думаем, должно пройти не менее полугода, прежде чем можно будет получить какую-то статистику, понять, как работает закон, и приобрести опыт проведения первых торгов.
Что до остального, то в честной конкуренции побеждает тот, кто умеет выполнять свою работу лучше и уже доказал это. Должны быть успешные проекты, удовлетворенные заказчики и умение выстраивать долгосрочные партнерские отношения.
Геннадий КОПАЕВ
Часто общаясь с представителями федеральной и региональной власти, мы видим следующую картину: там, где использование ИТ-решений переведено в практическую плоскость, используются реальные решения. А вот в случае работы «на полку» возможно использование и «фантастических» систем. Известный тезис «практика – критерий истины» применим и в данном случае. Поэтому необходима работа по экспертному развитию темы, принятие нормативно-правовых актов, а также давление регулирующих органов власти для обеспечения практического внедрения.
Использование каких именно технологий, на ваш взгляд, наиболее перспективно для организации эффективного и надежного предоставления электронных госуслуг?
Юрий АКАТКИН
Перспективным является применение таких технологий, которые строятся на принципах интероперабельности, ориентированы на сервисную архитектуру (SOA 2.0) и при этом учитывают семантический уровень интеграции. Следует обратить внимание и на американский стандарт NIEM, и на европейские стандарты. Однако и в России уже существуют решения, объединившие современные международные технологии и опыт их применения для подготовки государственных услуг к переводу в электронный вид. С технической точки зрения при такой размерности информационного пространства, какая возникает при межведомственном обмене данными, невозможно обойтись без промышленных технологий, без использования языков программирования, которые подразумевают манипуляции с объектами моделей данных, автоматическую интерпретацию метаданных.
Максим БАРСУКОВ
Предоставление электронной госуслуги – это вершина «айсберга» из различных информационных систем. Требования к технологиям на каждом уровне систем могут существенно различаться. На мой взгляд, обязательно должна быть определена техполитика и организован технологический надзор над всеми разработками в рамках госконтрактов, и не только в рамках госуслуг. Данная задача чрезвычайно важна, ее реализация очень сильно повлияет на эффективность и надежность предоставления электронных госуслуг.
Андрей БУРИН
В первую очередь это SOA как базовый принцип обеспечения взаимодействия разнородных информационных систем. Эта технология хороша тем, что универсальна и может использоваться везде, где требуется интегрировать информационные источники и ресурсы .
BI, портальные, облачные технологии, ECM, BPM – спрос на информационные системы, автоматизирующие отдельные функции учреждений и ведомств в регионах, растет. Эта потребность сформировалась буквально за последние несколько лет. Спрос на ИТ в регионах – это катализатор развития всей отрасли, поскольку на федеральном уровне первичный уровень автоматизации давно пройден и главные усилия сейчас сфокусированы на дальнейшем развитии и интеграции существующих систем.
Геннадий КОПАЕВ
Мы видим, что не хватает систем класс BPM, причем правильных BPM, а не СЭД. Конечно, нужны интеграционные решения для взаимодействия с ведомственными информационными системами.
