CC BY
49
УДК: 681.3.06, 351
И. А. Шмидт
Пермский государственный технический университет
А.В. Шлыков
Центр производства информационных систем ГК ИВС, г. Пермь
ИНТЕРАКТИВНЫЕ ГОСУДАРСТВЕННЫЕ УСЛУГИ: СУТЬ, ПЕРСПЕКТИВЫ, ПРОБЛЕМЫ
Рассматриваются вопросы, связанные с оказанием государственных интерактивных (электронных) услуг в рамках концепции «Электронное правительство». Предлагается подход, основанный на использовании унаследованных информационных систем и сервисной шины. Сформулированы проблемы нормативной базы, препятствующие построению таких систем.
Термины «электронное правительство» и «предоставление государственных услуг в электронном виде» все чаще упоминаются в выступлениях государственных лиц, звучат в печати. Официальные источники [1, 2] во многом не поясняют, а, наоборот, затуманивают суть проблемы. Задекларированной целью электронного (интерактивного) предоставления государственных услуг является «повышение качества и доступности, предоставляемых гражданам и организациям, государственных услуг, упрощение процедуры и сокращение сроков их оказания, снижение административных издержек со стороны граждан и организаций, связанных с их получением, внедрение единых стандартов обслуживания граждан».
Попытаемся разобраться, что реально можно сделать в этой сфере и как это может работать. Рассмотрим также, какие проблемы мешают нам добиться желанной цели.
Для начала рассмотрим состояние информатизации в различных государственных и муниципальных органах. Налицо так назы-
ваемая «лоскутная автоматизация», когда автоматизируются отдельные процессы на отдельных участках, при этом межсистемной интеграции нет не только между различными органами, но и внутри них. Например, в подразделении УФМС выдача внутренних и заграничных паспортов учитывается при помощи разных информационных систем, которые никак друг с другом не связаны.
Необходимо отметить, что эти системы, как правило, хорошо встроены в существующие процессы и за время эксплуатации в них накоплено большое количество данных.
Как правило, в дискуссиях об электронном правительстве обсуждаются вопросы транспорта данных и формата их использования, при этом совершено не звучит тема автоматизации собственно управленческих процессов. Мы сделаем упор на обсуждении собственно организации предоставления государственной услуги (ГУ) в электронной форме как процесса. Отказ от существующих систем и построение «с нуля» некой единой общегосударственной информационной системы, которая будет выполнять все процессы, связанные с предоставлением ГУ, можно считать чистой утопией. Единственный жизнеспособный вариант - это построение системы предоставления ГУ на основе интеграции существующих систем.
Архитектура системы. Система получения электронных государственных услуг должна представлять собой распределенную структуру, позволяющую заявителям (получателям услуг) получить доступ к ним через Интернет. Точкой входа для получения услуг должны быть порталы государственных или муниципальных органов (далее портал ГУ). Взаимодействие между порталами ГУ разного уровня может быть налажено, благодаря возможности перехода пользователей с порталов региональных порталов на вышестоящие и нижестоящие порталы, а также на ведомственные порталы и обратно по гиперссылкам. Через портал ГУ заполняются различные формы, бланки документов, входящие в состав информации для оказания ГУ и запускается процесс оказания услуги. Также через портал заявитель может получить всю информацию о состоянии услуги (этапе прохождения ее через систему получения электронных ГУ).
Наибольший интерес с точки зрения их автоматизации представляют услуги, которые при их реализации требуют взаимодействия двух или более ведомств. Архитектура системы, обеспечивающей предоставление государственных услуг при взаимодействии нескольких ведомств, будет иметь вид, представленный на рисунке.
Удостоверяющий
центр
Рис. Архитектура системы предоставления государственных услуг
В основу архитектуры положена подсистема межведомственного взаимодействия - интеграционная платформа на основе сервисноориентированной архитектуры и корпоративной сервисной шины (ESB) [3].
Назначением подсистемы является обеспечение:
- информационного взаимодействия ведомственных систем;
- централизованного ведения информации об интеграционном ландшафте (системы-участники, описание структуры и форматов данных, участвующих в обмене);
- администрирования процессов обмена информацией между информационными системами.
Интеграционная платформа должна иметь открытые интерфейсы для возможной доработки и интеграции с другими системами.
Существующие ведомственные системы оснащаются дополнительными, специально разработанными адаптерами для подключения к системе взаимодействия. Адаптеры умеют работать с сообщениями от/из сервисной шины, которая при таком подходе является транспортом для гарантированной передачи событий/сообщений определенного формата между слабосвязанными системами.
Если ведомственная система имеет некоторое API, которое позволяет обращение к своим функциям «со стороны», адаптер будет использовать эти вызовы. Если такой возможности нет, адаптер будет вынужден обращаться непосредственно к данным такой системы. В этом случае адаптер может быть достаточно сложным. Разработка адаптеров для различных ведомственных систем будет наиболее трудоемкой задачей при включении существующих информационных систем в интегрированную систему предоставления электронных государственных услуг. Существенным преимуществом описанного подхода является возможность подключения новых систем постепенно.
Реестр ГУ. В системе должна быть обеспечена возможность составления цепочек управленческих процессов предоставления ГУ (workflow). Управление цепочками управленческих процессов возлагается на отдельную информационную подсистему - реестр ГУ, которая также подключается к корпоративной сервисной шине. Основными функциями реестра ГУ являются:
- выстраивание цепочек процессов в ходе исполнения ГУ, диспетчеризация событий/сообщений между прикладными программными системами, в том числе с учетом логических условий;
- сбор и хранение информации о ходе оказания всех ГУ, прошедших через систему;
- отслеживание регламента ГУ и исполнительской дисциплины всех участников процесса ее предоставления.
Функции по ведению реестра должны быть закреплены только за одним участником информационного обмена (оператором реестра ГУ).
Поясним на примере, в чем именно заключается функция диспетчеризации событий/сообщений в ходе исполнения ГУ. Рассмотрим гипотетическую услугу, связанную с владением недвижимости. Это значит, что ведомственная система, оказывающая услугу, посылает запрос с данными заявителя (сообщение). Реестр ГУ пересылает это сообщение ведомственной системе БТИ, которая ищет недвижимость, принадлежащую заявителю. Результат поиска в виде сообщения пересылается реестром ГУ в исходную систему, которая продолжает предписанную цепочку. (Вот она workflow). Завтра мы поменяем бизнес-процесс (регламент оказания ГУ): пусть требуется получить сведения не только на самого заявителя, но и на его супругу.
Теперь реестр ГУ должен обратиться в ведомственную систему ЗАГС (найти супругу), затем последовательно отправить данные как самого заявителя, так и найденной супруги в БТИ, и после получения ответа вернуть результаты первой системе. Все изменения в регламенте оказания ГУ отслеживаются именно реестром ГУ, ведомственные системы могут даже не подозревать об изменениях.
Послезавтра в тот же бизнес-процесс можно встроить или, наоборот, заменить/исключить какую-либо систему. Реестр ГУ должен быть перенастроен для управления новой цепочкой.
Еще одной особенностью реестра ГУ должна быть способность отработки ситуаций ветвления цепочки процессов в зависимости от выполнения условия (например, военкоматовская система получает запрос, только если заявитель мужского пола). Также ветвление может выполняться в зависимости от результата выполнения предыдущего процесса. Особым случаем является прерывание выполнения ГУ, если, например, заявитель не прошел проверку на каком-либо этапе.
И, наконец, возможен вариант, когда выполнение услуги переводится в ручной режим, такое может быть в нестандартных ситуациях, когда решения должны приниматься человеком. Реестр ГУ должен обеспечивать как перевод услуги в ручной режим, так и возврат ее в поток автоматизированной обработки.
Обеспечение безопасности. Для удостоверения полномочий ведомственных систем в составе участников информационного обмена, а также для организации защищенного обмена информацией предусматривается использование иерархической структуры удостоверяющих центров для выдачи и обмена сертификатами. Необходимость использования передачи информации с использованием средств защиты определяется регламентом оказания ГУ.
В удостоверяющих центрах, включенных в систему получения электронных государственных услуг, должны применяться сертифицированные ФСБ средства криптографической защиты информации.
Использование системы предоставления электронных ГУ. Рассмотрим, как приведенная схема будет выполнять свою задачу.
Для исполнения услуги заявитель должен заполнить регистрационную форму на портале ГУ и предоставить (заполнить) необходимые для данной услуги документы. Процедура предоставления электронных копий документов и их легитимность должны быть закреплены какими-либо нормативными документами. На первом этапе процесс предоставления заявителем документов или их копий может быть организован на основе личного присутствия.
Регламент исполнения ГУ прописан в цепочках управленческих процессов, которые отслеживаются реестром ГУ.
Информация, необходимая для начала процесса, из портала пересылается в соответствующую ведомственную систему (куда именно - решение принимается реестром ГУ), и процесс оказания услуги начинается.
При завершении каждого звена процесса необходимое событие/сообщение пересылается ведомственной системой (его адаптером) в реестр ГУ, который решает, что делать дальше. Таким образом, текущее состояние услуги и вся его история всегда известны реестру. При помощи портала заявитель всегда имеет возможность посмотреть состояние своей заявки и проследить процесс получения услуги. Также заявитель имеет право при необходимости информировать исполнителя услуги о каких-либо замеченных ошибках и недочетах в процессе ее исполнения.
Весь информационный обмен происходит через подсистему межведомственного обмена.
По завершении исполнения либо по необходимости присутствия заявителя последнему направляется информационное сообщение на портал ГУ либо на личный электронный адрес с соответствующей информацией. Документы и/или результат услуги по завершении исполнения услуги высылаются заявителю по почте или выдаются лично в соответствующем органе власти, который исполнил ГУ.
Имеющиеся проблемы. Проблемы, мешающие получить замечательную картину, описанную выше, имеют не техническую (все, что описано, реализуемо за вполне реальные сроки и деньги), а организационно-правовую природу.
Основной проблемой является, на наш взгляд, отсутствие каких-либо правовых актов, позволяющих организовать на правовой основе предоставление тех или иных ГУ в интерактивном режиме. Если разбирать более детально, то можно выделить следующие аспекты.
Во-первых, идеология систем на основе ЕББ лежит вне правового поля, это значит, что такие понятия, как сообщение, процесс и прочие, никак юридически не подкреплены, то есть просто невозможно в юридических терминах описать взаимодействие нескольких информационных систем, а можно только написать что-то вроде «Ведомство А передает ведомству Б следующие сведения...». Юристы под этим понимают, что ведомство А подготовит нужные сведения, распечатает их и в таком виде передаст ведомству Б. Соответственно, невозможно защитить при помощи электронной цифровой подписи (ЭЦП) передаваемые данные, так как в законе [4] точно указано, что ЭЦП это реквизит электронного документа - ключевое слово здесь документ.
Во-вторых, не существует правовых оснований передачи каких-либо сведений из одного ведомства в другое. Более того, в ведомственных инструкциях обычно указано, что сведения могут быть переданы только органам следствия, судам и т. п.
Особую проблему представляет передача информации между ведомствами различного уровня подчинения: федеральными, региональными и муниципальными.
Отдельным аспектом передачи информации является необходимость выполнять требования закона о персональных данных [5] (большая часть информации, передаваемой в целях исполнения ГУ, будет относиться к персональным данным). Это очень важная тема, обсуждение которой требует отдельной статьи. Сейчас упомянем, что буквальное толкование некоторых положений этого закона и ряда сопутствующих подзаконных актов фактически делает передачу сведений персонального характера за границы конкретной системы невозможной, более того, зачастую будет невозможна и сама обработка персональных данных.
В-третьих, для интерактивного получения ГУ необходима идентификация заявителя. Это отдельный серьезный вопрос, выходящий за рамки данной статьи.
Наиболее радикально этот вопрос решается в Эстонии, где введена программа Ю-карт. Эстонская Ю-карта является обязательной для всех жителей с 15 лет, проживающих временно или постоянно на территории Эстонии. Владелец карты автоматически получает возможность электронной подписи. При помощи электронной подписи можно принять участие в голосовании, отправить налоговую декларацию, таможенную декларацию, различные анкеты как в местные органы самоуправления, так и в государственные органы. Все это осуществляется через центральный гражданский портал Eesti.ee
В-четвертых, не определено, кто должен являться оператором реестра ГУ. У оператора должны быть достаточно серьезные полномочия по администрированию всех процессов межведомственного информационного взаимодействия. Возможно, нужно будет иметь операторов реестра федерального и регионального уровней.
Библиографический список
1. Стратегия развития информационного общества, утвержденная Президентом Российской Федерации 7 февраля 2008 г. № Пр-212.
2. Постановление Правительства Российской Федерации от 25 декабря 2007 г. № 931 «О некоторых мерах по обеспечению
информационного взаимодействия государственных органов и органов местного самоуправления при оказании государственных услуг гражданам и организациям» // Собрание законодательства РФ.
- 2007. - № 53. - Ст. 6627.
3. Дэвид А. Шаппел. ЕББ - Сервисная Шина Предприятия, -СПб.: БХВ-Петербург, 2008.
4. Федеральный закон от 10.01.2002 № 1-ФЗ «Об электронной цифровой подписи».
5. Федеральный закон от 27.06.2006 № 152-ФЗ «О персональных данных».
Получено 09.07.2009
