CC BY
38
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ И РЕСУРСЫ
Универсальная архитектура информационной системы — инновационный подход к информатизации государственных услуг
Статья посвящена актуальным проблемам информатизации сферы государственных и муниципальных услуг в Российской Федерации и способам их решения путем построения в ведомствах информационных систем с универсальной кросс-региональной архитектурой. Основные принципы универсальной архитектуры сформированы в результате исследования сферы тарифного регулирования. Архитектура состоит из четырех уровней и охватывает сферу государственных и муниципальных услуг от уровня хранения данных до интерфейсов взаимодействия с получателями услуг. Универсальный характер предложенной архитектуры позволяет применять ее для построения информационных систем не только в рамках услуг тарифного регулирования, но и для прочих услуг ведомств.
Ключевые слова: государственные услуги, системная архитектура, информационные системы.
Информатизация сферы государственных и муниципальных услуг в настоящее время является одним из приоритетных направлений инновационной деятельности в государственном управлении [1]. Успешность проектов по информатизации сферы во многом определяет не только рейтинг страны на мировой экономической и политической арене, но и качество жизни получателей услуг государства.
Разработка информационных систем как любая инновационная деятельность характеризуется высокой степенью неопределенности требований, рисками и большим количеством неудачных проектов.
Основные проблемы информатизации сферы государственных и муниципальных услуг описаны в государственной программе Российской Федерации «Информационное общество (2011-2020 гг.)» (далее — Программа) [1]. Однако практический опыт показывает, что список проблем информатизации на самом деле шире. В свою очередь, пути решения проблем представляют собой не что иное, как требования к архитектуре информационной системы. В таблице представлено видение проблем и путей их решения, сформированное на основе работы со сферой тарифного регулирования.
Существующие информационные решения в сфере государственных и муниципальных услуг не решают обозначенные проблемы. Так, наиболее масштабный проект в области информатизации государственных услуг — портал «Электронное правительство. Госуслуги» — запущенный в 2009 г., все еще находится в самом начале своего внедрения согласно докладу Министерства связи и массовых коммуникаций Российской Федерации, опубликованному в октябре 2013 г. и положенному в основу Концепции развития механизмов предоставления государственных и муниципальных услуг в электрон-
К. В. Кутикова,
менеджер продукта, ООО «ИСМ»
kkutikova@yandex.ru
ном виде [2]. Об этом свидетельствуют следующие тезисы доклада:
• доля корректной и актуальной информации о порядке предоставления услуг составила 47,5% для федеральных услуг и 54% для региональных;
• возможность подачи заявления в электронном виде реализована только для 11,3% федеральных услуг и 16,9% региональных, хотя согласно Программе возможность должна быть реализована для всех услуг;
• не фиксируется статус процесса выполнения услуги. Потребители, соответственно, не имеют возможности статус отслеживать.
Еще один проект — система «Единый центр регистрации юридических лиц», работающая по принципу «одного окна» в подразделениях министерства по налогам и сборам Российской Федерации — охватывает этап подачи документов получателем услуги, но не улучшает сам процесс оказания услуги внутри ведомства, а, следовательно, время и качество процесса остаются на прежнем уровне.
Для достижения целей, заявленных в Программе [1], порталы, позволяющие потребителю обратиться за получением услуги, архитектурно должны являться верхушкой «айсберга» информатизации органов государственной и муниципальной власти, витриной, отображающей итоговые данные полностью интегрированных в информационную систему внутренних процессов. В основе же должна лежать расширяемая информационная система, построенная по единым принципам и внедренная на всех уровнях и во всех ведомствах, задействованных в процессе оказания услуги.
Для того, чтобы архитектура системы была надежной опорой для верхушки «айсберга», она должна удовлетворять следующим требованиям:
• высокий уровень абстракции — базовые правила работы системы одинаковы для всех отделов или
ю
о
со
СП
<
00 О X X
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ И РЕСУРСЫ
Проблемы информатизации сферы государственных и муниципальных услуг, и требования к архитектуре информационной системы
№ Проблемы из Программы [31 Проблемы «как есть» Требования к разработке информационной системы
1 Локальный характер внедрения информационных систем, различных от ведомства к ведомству Характер внедрения зачастую носит даже не «локальный», а «лоскутный» характер, когда информатизируется часть процесса, без учета полного цикла процесса и/или смежных процессов. Еще больше осложняет ситуацию то, что автоматизация может быть фрагментарной не только в разных ведомствах, но даже в разных отделах одного ведомства. Локальное информационное решение подразумевает возможность его легкой состыковки с решениями, которые через какое-то время будут внедрены в смежном отделе или ведомстве. Построение единой системы в этом случае - всего лишь вопрос времени. Если в ведомстве начата лоскутная автоматизация, то сколько бы времени ни прошло, к появлению единой системы она не приведет. Программные приложения разных отделов, как лоскутки, не смогут состыковаться «краями». В этом случае единственный выход - проектировать систему заново, не пытаясь «перекроить» существующие программные приложения Архитектура информационной системы должна быть а) разработана; б) согласована группой разработки с руководством ведомств, участвующих в процессе оказания государственной или муниципальной услуги. Архитектура системы должна учитывать не только текущие, но и перспективные задачи ведомств и отрасли. Несмотря на очевидность данного требования, соблюдается оно далеко не всегда - руководители редко заглядывают дальше краткосрочных задач, что приводит к появлению сиюминутных решений, быстро теряющих свою актуальность
2 Различие архитектур информационных систем во взаимодействующих органах власти, а также отсутствие в программно-технических решениях универсальных/совместимых механизмов обмена данными В конкурсной документации на разработку информационных систем для органов власти, как правило, значится пункт об интеграции с внешними системами. Но зачастую от разработчика требуется обмен данными только с одной-двумя конкретными системами. Из виду в этом случае упускается возможность смены или дополнения систем в органах власти, с которыми было прописано взаимодействие. В этом случае интеграция, жестко реализованная в программе, становится бесполезной Одним из блоков архитектуры системы в обязательном порядке должен быть функционал обмена данными, независимый от архитектуры системы, из которой поступили данные. Иными словами, в информационную систему нужно закладывать возможность выгрузки/ загрузки данных в унифицированном формате (например, в хт1) и обработчик входящих хт1 от сторонних систем
3 Отсутствие взаимодействия федеральных и региональных информационных систем между собой Опыт работы с проектами в сфере тарифного регулирования показывает, что эта проблема имеет две стороны - техническую и организационную. Техническая проблема уходит корнями в разницу архитектур и отсутствие механизмов обмена данными на разных уровнях органов власти. Организационная заключается в том, что существующие регламенты взаимодействия органов власти ориентированы в первую очередь на бумажную отчетность. Когда в процесс взаимодействия включается информационная система, требуются электронные регламенты, которые регулируют взаимодействие типа «федеральное ведомство - информационная система - региональное ведомство» Архитектура информационной системы должна быть кросс-уровневой, т. е. система должна иметь систему прав доступа и настройки, позволяющие ей быть внедренной в ведомствах -участниках процесса, на разных уровнях иерархии органов власти. В этом случае вероятность применения системы не только на региональном, но и на федеральном уровне значительно повышается
4 Если несколько ведомств все-таки на информационном уровне взаимодействуют, то наблюдается фрагментарный характер их взаимодействия. Это означает, что ведомства обмениваются данными на одном этапе процесса оказания услуги, но в то же время могут быть абсолютно изолированы друг от друга на другом этапе этого же процесса При проектировании архитектуры системы для сферы государственных и муниципальных услуг нужно, в первую очередь, отталкиваться от процессов и их участников, при этом имеет смысл рассматривать сквозные межведомственные процессы как единое целое, а не как серию изолированных процессов. Такой подход к анализу процессов позволяет выявить этапы, на которых для оказания услуги необходимы данные или согласование смежного ведомства
5 Совместная работа ведомств на каком-то этапе процесса оказания услуги влечет за собой проблему владения данными. На практике мы часто сталкивались с ситуацией, когда два ведомства изолированно ведут историю значений какого-то показателя, оправдывая это тем, что а) либо законодательство не говорит в явном виде, за кем должна быть закреплена эта работа; б) либо запрос данных у ведомства-владельца сопряжен с организационными трудностями. В итоге - каждое ведомство пользуется своей версией данных, и непонятно, какие же значения правильные. Наглядный пример такой проблемы - ситуация с расчетом социальной нормы на потребление электроэнергии. В расчете участвует показатель «Количество человек, зарегистрированных в квартире». Этими данные обладает Федеральная миграционная служба, но в ее обязанности не входит обмениваться этими сведениями. Частично эту информацию также ведут органы муниципальной власти, собирая ее самостоятельно. А расчет соц. нормы производит региональный орган тарифного регулирования, для которого получение этих данных является большой проблемой, и по факту он зачастую собирает их заново и децентрализованно, по телефону Еще на этапе сбора требований к системе необходимо четко зафиксировать принцип «одного владельца» данных и назначить каждому блоку данных своего владельца, ответственного за поддержание их целостности и актуальности. Если у других участников системы в ходе работы появляются свои версии этих данных, то они не заменяют исходные, а сверяются с ними. Решение об изменении данных всегда остается за владельцем. При этом система должна обеспечивать доступ нужного уровня для остальных участников процесса. Ручное внесение данных из одной системы в другую - плохая практика
ведомств, вовлеченных в процесс. Работа системы на всех уровнях власти должна быть аналогична; типизация основных процессов — процессы оказания услуг реализованы в виде объектов (в контексте системы называемых «записями») разных типов. При этом типы записей обладают определенным набором характеристик, число типов конечно. Увы, зачастую при информатизации оцифровываются не процессы, а расчетные методики, хотя на самом деле методики являются вторичными по отношению к процессу и меняются значительно чаще;
параметризация настроек системы — при подключении еще одного процесса оказания государственной или муниципальной услуги система легко расширяется, реализуя особенности нового
компонента настройками. Настройки позволяют расширять систему не только по горизонтали (подключение нового процесса), но и по вертикали, добавляя к процессу связанные с ним аналитические надстройки и порталы. Модульность системы позволяет внедрять ее постепенно, сохраняя устойчивость;
хранилище данных, структура которого минимально зависит от изменения законодательства — хранение данных спроектировано таким образом, чтобы его структура была, насколько это возможно, открытой, что позволяет не зависеть ни от изменений законодательства, ни от вариантов аналитики, которая требуется руководству. Каждый показатель в системе имеет своего владельца, который представляет собой конкретное должностное
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ И РЕСУРСЫ
лицо в ведомстве, отвечающее за актуальность и достоверность вносимых данных. Если процесс оказания услуги подразумевает совместную работу с данными специалистами разных отделом или ведомств, то данные, внесенные владельцем, автоматически доступны для работы другим участникам. Система исключает задачи повторного внесения участниками процесса данных, полученных от их владельца.
Информационная система для сферы тарифного регулирования представляет собой структуру из четырех уровней:
1. Master Data Management (далее — MDM) — система реестров, содержащая в себе перечни юридических лиц, инфраструктуры и потребителей и их характеристики, а также служебные реестры — адресов, земельных участков и видов деятельности. Данные, содержащиеся в реестрах, необходимы для формирования единого баланса региона, который отображает взаимосвязь объектов инфраструктуры, юридических лиц, предоставляющих услуги на базе этой инфраструктуры и потребителей этих услуг. Подобная структура MDM позволяет отслеживать любые изменения в режиме реального времени и обеспечивает перекрестный контроль данных. Для масштабирования системы до уровня страны необходима интеграция данных региональных регуляторов с системами смежных ведомств.
2. Business Process Management (далее — BPM) — платформа, обеспечивающая проведение в системе процессов оказания государственных и муниципальных услуг, а в сфере тарифного регулирования в первую очередь процессов обработки заявлений получателей услуг: экспертизу, выполнения контрольных, ревизионных и иных функций ведомств. На первоначальном этапе внедрения информати-зируются простейшие рутинные операции, соответственно, под процессами в дальнейшем будем иметь в виду и их тоже.
3. Applied Applications — подключаемый набор надстроек для решения расчетных и аналитических задач, возникающих в рамках процесса оказания услуги.
4. Portal and Business Intelligence Applications — приложения, предназначенные для двух основных задач: а) взаимодействие с получателями услуг; б) предоставление аналитики высшему руководству ведомства или региона и обеспечение возможности мониторинга ситуации с тарифами и платежами граждан. Аналитические приложения строятся на принципах BI.
Для взаимодействия с внешними системами предусмотрен служебный блок — платформа интеграции. Наиболее часто интеграция происходит с уже внедренными в ведомствах системами электронного документооборота (далее — СЭД). В этом случае данные из внешней СЭД передаются на уровень BPM и запускают или закрывают процесс оказания услуги.
Единство архитектуры на различных уровнях ведомства и в различных регионах являются реализацией принципа иерархичности. Типовые интерфейсы, заложенные в систему на этапе проектирования, вы-
ступают гарантом того, что интеграция систем разных ведомств и уровней пройдет без ущерба для архитектуры систем.
Внедрение системы с универсальной модульной архитектурой позволяет органам власти не только сократить расходы бюджетных средств по сравнению с внедрением решений, отличающихся архитектурно, но и распределить расходы во времени, выбирая минимально необходимый на текущий момент набор модулей реестровых и процессных уровней и в дальнейшем дополняя его желаемыми аналитическими надстройками и портальными решениями.
А для компаний-разработчиков благодаря предложенной архитектуре значительно снижаются затраты на поддержку и масштабирование продуктовой линейки.
Список использованных источников
1. Государственная программа Российской Федерации «Информационное общество (2011-2020 гг.)»: распоряжение Правительства РФ от 20 октября 2010 г. № 1815-р с изменениями от 18 мая, 2, 30 декабря 2011 г., 5 мая, 15 августа, 10, 27 декабря 2012 г., 20 июля 2013 г.//Российская газета (Интернет-портал), 29 июля 2013.
2. Распоряжение Правительства Российской Федерации № 2516-р от 25 декабря 2013 г. об утверждении Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде//Российская газета (Интернет-портал), 30 декабря 2013.
3. Распоряжение Правительства Российской Федерации № 1789-р от 25 октября 2005 г. об утверждении Концепции административной реформы в Российской Федерации в 20062008 гг. и соответствующий план мероприятий//Российская газета (Интернет-портал), 24 июля 2009.
4. Э. Халл, К. Джексон, Дж. Дик. Разработка и управление требованиями: практическое руководство пользователя, Springer Science+Business Media, 2005.
5. В. И. Грекул, Г. Н. Денишенко, Н. Л. Коровкина. Проектирование информационных систем. М.: Интернет-ун-т информ. технологий, 2005.
6. Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов, Проектирование экономических информационных систем. М.: Финансы и статистика. 2001.
7. Е. А. Петрова. Зарубежный опыт информатизации и особенности его реализации в России//Волгоградский государственный университет. Фундаментальные исследования, № 11, 2007.
8. Е. Н. Мельникова. Экономическая эффективность информационных проектов для органов государственного регионального управления//Вестник ВолГУ. Серия 9. № 9. 2011.
9. К. И. Квятковский, В. Ф. Шуршаев, Проектирование информационных систем для органов государственной власти// Вестник АГТУ. Серия: «Управление, вычислительная техника и информатика». № 1. 2011.
Universal information system architecture as an innovative approach to public services informatization
о
CM
K. V. Kutikova, product manager, LLC «ISM». ^
The article is devoted to topical problems of Russian ^
public services informatization and ways of its resolving 3
by using universal cross-regional information system см
architecture. The main principles of the architecture were ^
appeared as the result of rate regulation sphere investigation. ^
The architecture includes four levels and spreads from data S
level to customers interface interaction level. Properties of jj
the architecture allow to applying it not only to rate regulation CQ
sphere but other public services. ^
Keywords: public services, system architecture, x
information systems. S
