CC BY
81
No. 6 (54) 2014
JOURNAL of APPLÍED INFORMATICS
К. В. Кутикова, аспирант Санкт-Петербургского государственного университета, kkutikova@yandex.ru Н. В. Ильина, менеджер продукта ООО «ИСМ», г. Москва, ni.septima@gmail.com
Методика проектирования информационных систем для сферы государственных и муниципальных услуг
В статье рассмотрены проблемы информатизации сферы государственных и муниципальных услуг в Российской Федерации . В сфере тарифного регулирования авторами разработана архитектура кросс-региональной информационной системы . Опыт ее разработки обобщен авторами и представлен в виде методики построения архитектуры систем масштаба страны в сфере государственных и муниципальных услуг . Также освещены вопросы разработки электронных административных регламентов в сфере оказания государственных и муниципальных услуг и их реализация в системе с описанной архитектурой .
Ключевые слова: универсальная архитектура системы, информационные системы, методика проектирования, информатизация, государственные и муниципальные услуги, требования к архитектуре
введение
В современном мире информатизация охватывает все сферы жизни общества. Государственные и муниципальные услуги не являются исключением. Началом целенаправленной информатизации этого направления на уровне государства можно считать 2008 г., когда были приняты соответствующие нормативно-правовые акты [1, 3]. Информатизация деятельности государственных и муниципальных органов является насущным вопросом и согласно Программе [3] должна быть завершена к 2020 г. От успеха проекта по информатизации во многом зависит не только рейтинг страны на мировой экономической и политической арене, но и качество нашей жизни как получателей услуг государства.
В процессе информатизации необходимо решить целый ряд задач, требующих координации различных ведомств и стратегического подхода к решению. Основная задача состоит в разработке архитектуры, удовлетворяющей целому ряду требований.
1. В архитектуру на этапе проектирования нужно закладывать средства для решения не только текущих, но и перспективных задач отрасли и ведомства.
2. Обязательным компонентом архитектуры должна быть подсистема обмена данными со сторонними системами.
3. Архитектура системы не должна зависеть от уровня ведомства, в котором она внедряется. На всех уровнях власти ведомства, работающие в одной отрасли, должны работать с однотипными объектами.
4. Ключевым элементом архитектуры должен быть блок по автоматизации процессов, а не методических расчетов.
5. В рамках архитектуры должно быть грамотно спроектировано хранилище данных — с соблюдением принципов реляционных баз данных и возможностью передачи данных в системы BI.
Несмотря на явный упор на функции в законодательном определении термина государственной или муниципальной услуги [2], при разработке информационной системы в этой сфере важно придерживаться
№ 6 (54) 2014
процессного подхода. Именно процессы как основа системы позволяют разработать модульную и открытую архитектуру, элементы которой совместимы между собой.
К сожалению, нередко информатизиру-ется только часть процесса в виде, например, порталов услуг, которые автоматизируют подачу заявки, но не касаются этапов ее обработки внутри соответствующего ведомства как неотъемлемой части процесса работы ответственного за это специалиста/ специалистов. Начиная информатизацию, нужно иметь силы и ресурсы дойти до конца — в единую информационную систему должны быть включены все рабочие места участников процесса.
Учитывая количество органов власти и услуг, создание такой архитектуры системы, безусловно, требует напряженной совместной работы представителей разных ведомств. Но разработать ее — вполне реально. Нами предложен возможный вариант масштабируемой архитектуры и методики ее построения, созданный на основе опыта проектирования информационной системы в сфере тарифного регулирования, и в частности, для процесса оказания услуг по установлению тарифов. К сфере тарифного регулирования относится большинство коммунальных, жилищных и транспортных услуг. Основную работу по расчету, утверждению и контролю тарифов ведут органы исполнительной власти субъектов Российской Федерации в сфере тарифного регулирования (так называемые региональные регуляторы). Тарифы рассчитываются и устанавливаются в рамках деятельности по оказанию государственной услуги юридическому лицу, ведущему регулируемую деятельность, на основании его заявления.
Архитектурно информационная система состоит из 4 уровней:
1) уровень данных, который включает в себя реестры основных объектов предметной области;
2) уровень бизнес-процессов, позволяющий настроить работу системы таким об-
разом, чтобы вся деятельность специалиста в рамках процесса осуществлялась через информационную систему;
3) аналитические надстройки, автоматизирующие методики расчета и предоставляющие аналитические инструменты;
4) веб-порталы, представляющие собой интерфейс обмена данными с получателями услуг, и В1-приложения, позволяющие руководству проводить анализ ситуации в ведомстве или отрасли.
Особенности архитектуры подробно описаны в данной статье. Все кейсы и примеры, которые приводятся авторами — из сферы тарифного регулирования на уровне региональных органов власти. Конкретные шаги для построения аналогичного решения в другой сфере формализованы авторами в виде методики проектирования.
Обзор текущей ситуации
Основные проблемы информатизации сферы государственных и муниципальных услуг описаны в государственной программе Российской Федерации «Информационное общество (2011-2020 годы)» (далее — Программа) [3], а именно:
• локальный характер внедрения информационных систем, различных от ведомства к ведомству;
• различие архитектур информационных систем во взаимодействующих органах власти, а также отсутствие в программно-технических решениях механизмов обмена данными;
• отсутствие взаимодействия федеральных и региональных информационных систем.
Однако опыт показывает, что список проблем информатизации на самом деле шире. В свою очередь, пути решения проблем представляют собой не что иное, как требования к проекту информатизации. В табл. 1 представлено видение авторами проблем и путей их решения, сформированное на основе работы со сферой тарифного регулирования.
Таблица 1
Проблемы информатизации сферы государственных и муниципальных услуг и требования к архитектуре информационной системы
№ Проблемы из Программы [3] Проблемы «как есть» Требования к разработке информационной системы
1 Локальный характер внедрения информационных систем, различных от ведомства к ведомству Характер внедрения нередко носит даже не «локальный», а «лоскутный» характер, когда информатизируется часть процесса, без учета полного цикла процесса и/или смежных процессов. Еще больше осложняет ситуацию то, что автоматизация может быть фрагментарной не только в разных ведомствах, но даже в разных отделах одного ведомства. Локальное информационное решение подразумевает возможность его легкой состыковки с решениями, которые через какое-то время будут внедрены в смежном отделе или ведомстве. Построение единой системы в этом случае — всего лишь вопрос времени. Если в ведомстве начата лоскутная автоматизация, то, сколько бы времени ни прошло, к появлению единой системы она не приведет. Программные приложения разных отделов, как лоскутки, не смогут состыковаться «краями». В этом случае единственный выход — проектировать систему заново, не пытаясь «перекроить» существующие программные приложения Архитектура информационной системы должна быть: а) разработана; б) согласована группой разработки с руководством ведомств, участвующих в процессе оказания государственной или муниципальной услуги. Архитектура системы должна учитывать не только текущие, но и перспективные задачи ведомств и отрасли. Несмотря на очевидность данного требования, соблюдается оно далеко не всегда — руководители редко заглядывают дальше краткосрочных задач, что приводит к появлению сиюминутных решений, быстро теряющих свою актуальность
2 Различие архитектур информационных систем во взаимодействующих органах власти, а также отсутствие в программно-тех-нических решениях универсальных совместимых механизмов обмена данными В конкурсной документации на разработку информационных систем для органов власти, как правило, значится пункт об интеграции с внешними системами. Но нередко от разработчика требуется обмен данными только с одной-двумя конкретными системами. Из виду в этом случае упускается возможность смены или дополнения систем в органах власти, с которыми было прописано взаимодействие. В этом случае интеграция, жестко реализованная в программе, становится бесполезной Одним из блоков архитектуры системы в обязательном порядке должен быть функционал обмена данными, независимый от архитектуры системы, из которой поступили данные. Иными словами, в информационную систему нужно закладывать возможность выгрузки/загрузки данных в унифицированном формате (например, вхш1) и обработчик входящих хш1 от сторонних систем
3 Отсутствие взаимодействия федеральных и региональных информационных систем Опыт авторов показывает, что эта проблема имеет две стороны — техническую и организационную. Техническая проблема уходит корнями в разницу архитектур и отсутствие механизмов обмена данными на разных уровнях органов власти. Организационная заключается в том, что существующие регламенты взаимодействия органов власти ориентированы в первую очередь на бумажную отчетность. Когда в процесс взаимодействия включается информационная система, требуются электронные регламенты [7-9], которые регулируют взаимодействие типа «федеральное ведомство — информационная система — региональное ведомство» Архитектура информационной системы должна быть кросс-уровневой, т. е. система должна иметь систему прав доступа и настройки, позволяющую ей быть внедренной в ведомствах — участниках процесса, на разных уровнях иерархии органов власти. В этом случае вероятность применения системы не только на региональном, но и на федеральном уровне значительно повышается
Окончание табл. 1
№ Про иле мы «как есть» Требования к разработке информационной системы
4 Если все-таки несколько ведомств на информационном уровне взаимодействуют, то наблюдается фрагментарный характер их взаимодействия. Это означает, что ведомства обмениваются данными на одном этапе процесса оказания услуги, но в то же время могут быть абсолютно изолированы друг от друга на другом этапе этого же процесса При проектировании архитектуры системы для сферы государственных и муниципальных услуг нужно в первую очередь отталкиваться от процессов и их участников, при этом имеет смысл рассматривать сквозные межведомственные процессы как единое целое, а не как серию изолированных процессов. Такой подход к анализу процессов позволяет выявить этапы, на которых для оказания услуги необходимы данные или согласование смежного ведомства
5 Совместная работа ведомств на каком-то этапе процесса оказания услуги влечет за собой проблему владения данными. На практике мы часто сталкивались с ситуацией, когда два ведомства изолированно ведут историю значений какого-то показателя, оправдывая это следующим: а) либо законодательство не говорит в явном виде, за кем должна быть закреплена эта работа, б) либо запрос данных у ведомства-владельца сопряжен с организационными трудностями. В итоге — каждое ведомство пользуется своей версией данных, и непонятно, какие же значения правильные. Наглядный пример такой проблемы — ситуация с расчетом социальной нормы на потребление электроэнергии. В расчете участвует показатель «Количество человек, зарегистрированных в квартире». Этими данными обладает Федеральная миграционная служба, но в ее обязанности не входит делиться этими сведениями. Частично эту информацию также ведут органы муниципальной власти, собирая ее самостоятельно. А расчет социальной нормы производит региональный орган тарифного регулирования, для которого получение этих данных является большой проблемой, и по факту он нередко собирает их заново и децентрализованно, по телефону Еще на этапе сбора требований к системе необходимо четко зафиксировать принцип «одного владельца» данных и назначить каждому блоку данных своего владельца, ответственного за поддержание их целостности и актуальности. Если у других участников системы в ходе работы появляются свои версии этих данных, то они не заменяют исходные, а сверяются с ними. Решение об изменении данных всегда остается за владельцем. При этом система должна обеспечивать доступ нужного уровня для остальных участников процесса. Ручное внесение данных из одной системы в другую — плохая практика
No. 6 (54) 2014
Существующие информационные решения в сфере государственных и муниципальных услуг не решают обозначенные проблемы. Так, наиболее масштабный проект в области информатизации государственных услуг — портал «Электронное правительство. Госуслуги», запущенный в 2009 г., все еще находится в самом начале своего внедрения согласно докладу Министерства связи и массовых коммуникаций Российской Федерации, опубликованному в октябре 2013 г. и положенному в основу Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде [4]. Об этом свидетельствуют следующие тезисы доклада.
• Доля корректной и актуальной информации о порядке предоставления услуг составила 47,5% для федеральных услуг и 54% для региональных.
• Возможность подачи заявления в электронном виде реализована только для 11,3% федеральных услуг и 16,9% региональных, хотя согласно Программе возможность должна быть реализована для всех услуг.
• Не фиксируется статус процесса выполнения услуги. Потребители соответственно не имеют возможности статус отслеживать.
Еще один проект — система «Единый центр регистрации юридических лиц», работающая по принципу «одного окна» в подразделениях министерства по налогам и сборам Российской Федерации, — охватывает этап подачи документов получателем услуги, но не улучшает сам процесс оказания услуги внутри ведомства, а следовательно, время и качество процесса остаются на прежнем уровне.
Для достижения целей, заявленных в Программе [3], порталы, позволяющие потребителю обратиться за получением услуги, архитектурно должны являться верхушкой «айсберга» информатизации органов государственной и муниципальной власти, витриной, отображающей итоговые данные полностью интегрированных в информационную систему внутренних процессов.
В основе же должна лежать расширяемая информационная система, построенная по единым принципам и внедренная на всех уровнях и во всех ведомствах, задействованных в процессе оказания услуги. Для сферы тарифного регулирования «айсберг» выглядит следующим образом (рис. 1).
Рис. 1. Система оказания государственных и муниципальных услуг в сфере тарифного регулирования
Архитектура информационной системы для оказания услуг в сфере тарифного регулирования.
Для того чтобы архитектура системы была надежной опорой для верхушки «айсберга», она должна удовлетворять следующим требованиям:
• высокий уровень абстракции — базовые правила работы системы одинаковы для всех отделов или ведомств, вовлеченных в процесс. Работа системы на всех уровнях власти должна быть одинаковой;
• типизация основных процессов — процессы оказания услуг реализованы в виде объектов (в контексте системы называемых «записями») разных типов. При этом типы
№ 6 (54) 2014
записей обладают определенным набором характеристик, число типов конечно. Увы, зачастую при информатизации оцифровываются не процессы, а расчетные методики, хотя на самом деле методики вторичны по отношению к процессу и меняются значительно чаще;
• параметризация настроек системы — при подключении еще одного процесса оказания государственной или муниципальной услуги система легко расширяется, реализуя особенности нового компонента настройками. Настройки позволяют расширять систему не только по горизонтали (подключение нового процесса), но и по вертикали, добавляя к процессу связанные с ним аналитические надстройки и порталы. Модульность системы позволяет внедрять ее постепенно, сохраняя устойчивость;
• в хранилище данных, структура которого минимально зависит от изменения законодательства, хранение данных спроектировано таким образом, чтобы его структура была, насколько это возможно, открытой, что позволяет не зависеть ни от изменений законодательства, ни от вариантов аналитики, которая требуется руководству. Каждый показатель в системе имеет своего владельца, который представляет собой конкретное должностное лицо в ведомстве, отвечающее за актуальность и достоверность вносимых данных. Если процесс оказания услуги подразумевает совместную работу с данными специалистами разных отделов или ведомств, то данные, внесенные владельцем, автоматически доступны для работы другим участникам. Система исключает задачи повторного внесения участниками процесса данных, полученных от их владельца.
Информационная система для сферы тарифного регулирования представляет собой четырехуровневую структуру (рис. 2).
1. Master Data Management (далее — MDM) — система реестров, содержащая в себе перечни юридических лиц, инфраструктуры и потребителей и их характеристики, а также служебные реестры — адресов, земельных участков и видов деятель-
ности. Данные, содержащиеся в реестрах, необходимы для формирования единого баланса региона, который отображает взаимосвязь объектов инфраструктуры, юридических лиц, предоставляющих услуги на базе этой инфраструктуры, и потребителей этих услуг. Подобная структура MDM позволяет отслеживать любые изменения в режиме реального времени и обеспечивает перекрестный контроль данных. Для масштабирования системы до уровня страны необходима интеграция данных региональных регуляторов с системами смежных ведомств.
2. Business Process Management (далее — BPM) — платформа, обеспечивающая проведение в системе процессов оказания государственных и муниципальных услуг, а в сфере тарифного регулирования — в первую очередь процессов обработки заявлений получателей услуг: экспертизу, выполнение контрольных, ревизионных и иных функций ведомств. На первоначальном этапе внедрения информатизируются простейшие рутинные операции, соответственно, под процессами в дальнейшем мы будем подразумевать и их тоже.
3. Applied Applications (далее — AA) — подключаемый набор надстроек для решения расчетных и аналитических задач, возникающих в рамках процесса оказания услуги.
4. Portal and Business Intelligence Applications (далее — P&BI) — приложения, предназначенные для двух основных задач: а) взаимодействие с получателями услуг; б) предоставление аналитики высшему руководству ведомства или региона и обеспечение возможности мониторинга ситуации с тарифами и платежами граждан. Аналитические приложения строятся на принципах BI.
Для взаимодействия с внешними системами предусмотрен служебный блок — платформа интеграции. Наиболее часто интеграция происходит с уже внедренными в ведомствах системами электронного документооборота (далее — СЭД). В этом случае данные из внешней СЭД передаются на уровень BPM и запускают или закрывают процесс оказания услуги.
No. 6 (54) 2014
JOURNAL of APPLÍED INFORMATICS
Автоматизация деятельности региональных регуляторов не обходится без реинжиниринга их процессов. При внедрении систем нужен документ, который поможет зафиксировать новый порядок работы специалистов и взаимодействия между отделами — электронный административный регламент. Термину «электронный административный регламент», который встречается в различных нормативно-правовых актах [5-7], первое определение дано в ГОСТ Р 52294-2004 «Информационная технология. Управление организацией. Электронный регламент административной и служебной деятельности. Основные положения» [8]. Стоит отметить, что в отличие от обычных административных регламентов, в которых нередко зафиксированы процессы, не соответствующие реально сформировавшимся среди специалистов ведомства, электронный административный регламент призван связать реальные процессы деятельности органа власти и их реализацию в информационной системе.
Существенной проблемой при разработке электронных административных ре-
гламентов для всей отрасли или страны является их унификация — как на уровне процессов, так и на уровне данных [9]. Для устранения различий в данных ряд исследователей предлагают разработать классификатор показателей, участвующих в процессе оказания государственной и муниципальной услуг [9]. Способствовать приведению процессов к единому виду может внедрение информационных систем с описанной архитектурой на уровне ВРМ по всей вертикали органов власти.
Рассмотрим уровни архитектуры подробнее. Уровень MDM обеспечивает реализацию следующих функций:
• получение и поддержка в актуальном состоянии базы данных в разрезе организаций, инфраструктуры и потребителей;
• формирование и поддержка регламента, обеспечивающего проверку и гарантирующего корректность данных реестров;
• формирование баланса оказания услуг по различным видам деятельности в разрезе объектов территориально-административного деления;
Аналитические приложение для руководства Веб-порталы для получателей услуг
Portals and Business Intelligence Applications
Прикладные расчетно-аналитические надстройки
Applied Applications
BPM* Платформа
Типы записей для процессов
BPM
Хранилище данных
Реестр Реестр
организаций инфраструктуры
Реестр потребителей
MDM
ПЛАТФОРМА ИНТЕГРАЦИИ
Рис. 2. Архитектура информационной системы для предоставления государственных и муниципальных услуг в сфере тарифного регулирования
30
№ 6 (54) 2014
• выявление аномалий данных с помощью проверки связи с инфраструктурой и выверки фактических данных по филиальной сети;
• повышение эффективности учета регулируемых организаций за счет связи с инфраструктурой, учета видов деятельности по поселениям, учета потребителей;
• обеспечение интеграции с другими уровнями системы, оперирующими объектами реестров;
• осуществление согласованного обмена данными реестров с ведомствами других регионов и других уровней.
Основные реестры уровня MDM:
• перечень организаций (юридических лиц и органов власти);
• перечень объектов инфраструктуры;
• перечень потребителей.
Каждый объект реестра однозначно характеризуется уникальным идентификатором и описывается набором полей с возможностью отслеживания их изменения. Состояния жизненного цикла объектов описываются статусной моделью, функционирующей для всех реестров по единым правилам.
Процессные приложения (уровень BPM) связаны с объектами и являются следующим уровнем после реестров. Здесь происходит автоматизация рутинных операций и рабочих процессов оказания государственных и муниципальных услуг от момента получения заявления до выдачи результата потребителю. Единицей системы на уровне BPM является «запись». Использование платформы BPM позволяет обеспечить единый механизм обработки записей и интегрировать записи разных типов между собой. Основой функционирования платформы являются процессы, связанные с документооборотом ведомства. Эти процессы рассматриваются как сквозные и обслуживаются по единым стандартам. Для каждого процесса существует свой тип записей, учитывающих специфические особенности процесса. Каждый тип записи можно отнести к одной из следующих групп.
• Сквозные записи — единый тип записей, используемый во всех модулях платфор-
мы BPM. Универсальным типом, обеспечивающим коммуникации между отделами одного ведомства или ведомствами разных уровней, являются сигналы. Сигнал может быть привязан к нескольким организациям, причем при создании дочерних записей пользователь может выбирать из списка организаций сигнала, с какой организацией будет связана новая запись. С помощью сигналов передается любая неформализованная информация, все автоматически генерируемые системой оповещения и пакеты данных, поступающие в систему извне, а также создаваемые в системе для взаимодействия с другими модулями/отделами/организациями.
• Атомарные записи — каждая из них соответствует факту обработки одного запроса на услугу и содержит весь пакет материалов по этому запросу. В атомарных записях происходит сбор и обработка данных.
• Сводные записи — применяются для работы со сводными данными по группе организаций.
О прохождении записи по этапам процесса сигнализируют отметки системы или пользователей о завершении того или иного этапа. Отметки могут выставляться пользователями вручную или системой автоматически при наступлении события:
• поступлении той или иной информации;
• согласовании результатов проверки экспертом;
• наступлении контрольного срока.
При наступлении любого из перечисленных выше условий или их комбинации меняется этап и статус записи. Изменение может сопровождаться:
• отправкой уведомлений;
• открытием или блокировкой возможностей для редактирования разделов записи;
• передачей записи другим пользователям на согласование, утверждение или обработку.
Платформа уровня BPM представляет собой универсальный обработчик записей. Внешний вид приложения и конфигурация меню зависят от настроек конкретного пользователя, а точнее — от типов записей, ко-
No. 6 (54) 2014
торые доступны ему для обработки. Каждому типу записей соответствует свое меню. Таким образом, обеспечивается единая точка входа пользователей в систему и гибкая настройка их работы с любым комплектом типов записей.
Система, в которой работа с бизнес-процессами построена на платформе BPM, позволяет компании-разработчику сократить сроки разработки и масштабирования процессных решений.
Следующим уровнем системы являются конкретные расчетно-аналитические блоки. Доступ к аналитическим надстройкам осуществляется только из записей. Без подключения блоков уровня BPM расчет-но-аналитические надстройки недоступны пользователям, поскольку без информатизации процессов качество подготовки входящей информации недостаточно для адекватного анализа и расчетов. В общем случае надстройки представляют собой расчетные модели, регламентированные методиками, и аналитическую отчетность. Расчетная логика аналитической надстройки может различаться в зависимости от предметной области, но инструменты, которые система предлагает в ее рамках, унифицированы и включают в себя, но не ограничиваются ими, следующие:
• Условное форматирование значений показателей. Позволяет выделить цветом:
■ расхождение версий расчета;
■ отклонения текущих значений показателей от значений, рассчитанных системой на основе средних параметров по отрасли;
■ статус показателя, который информирует, проверен он специалистом или нет.
• Графические инструменты — выводятся отдельным окном рядом с основной рабочей областью. Для каждого показателя в системе предусмотрен свой набор графических инструментов.
• Комментарии при изменении значения показателя. В системе ведется история изменений значений показателей. При каждом изменении система предлагает пользовате-
лю внести причину изменения. Соответствующим образом помеченные замечания могут ложиться в основу автоматически формируемых итоговых документов — экспертных заключений, предписаний и т. п.
• Дополнительный запрос данных от организации или смежного ведомства по конкретному набору показателей. Обмен данными между участниками системы осуществляется через записи типа «Сигналы» уровня BPM.
На самом верхнем уровне архитектуры размещаются порталы для взаимодействия с получателями услуг и аналитические срезы для руководства. Они основаны на данных, хранящихся на уровне MDM, полученных в процессах на уровне BPM, а также сформированных в результате аналитических расчетных моделей. Решения верхнего уровня, не связанные единой логикой с теми уровнями системы, где непосредственно происходит работа по оказанию государственной или муниципальной услуги, — неэффективны. Без реестрового, процессного и аналитического уровней системы портальные решения со временем становятся статичными, обновление данных в них может происходить только вручную. Яркий пример такого портального решения мы наблюдали в одном из регионов: руководитель органа регулирования желает получить аналитическое приложение для мониторинга текущей ситуации в регионе и непосредственно в возглавляемом им органе власти. Однако деятельность специалистов регулятора не автоматизирована, данные разрозненны, отсутствует их единое хранилище. В такой ситуации вместо того, чтобы быть частью системы и упрощать работу органов власти, приложение лишь добавляет в процесс работы специалистов органа власти бесполезные этапы ручной поддержки целостности и актуальности данных приложения.
Методика проектирования архитектуры информационной системы для сферы государственных и муниципальных услуг.
Построить в других сферах информационную систему с архитектурой, описанной
№ 6 (54) 2014
для сферы тарифного регулирования, можно по следующим шагам:
1. Определение целей информатизации.
Прежде всего заинтересованные стороны проекта разработки системы должны совместно найти и зафиксировать ответ на вопрос «Каковы основные и второстепенные задачи системы?». Во-первых, от этого ответа зависит, какие процессы нужно учитывать при построении архитектуры. Во-вторых, степень правдивости согласованной сторонами цели прямо пропорциональна активности дальнейшего применения системы. Если цель, положенная в основу разработки, на самом деле не соответствует ожиданиям конечных пользователей, то система окажется мертвой — работать в ней не будут.
2. Описание процессов.
Для построения системы, автоматизирующей процессы оказания услуг, необходимо эти процессы описать. Мы обычно делаем это в серии интервью с пользователями, чередуя сбор требований, фиксацию схем процессов в виде блок-схем и повторное обсуждение уже зарисованного процесса с пользователями. Такой подход позволяет одновременно проводить реинжиниринг и оптимизацию процессов, а также позволяет пользователям системы глубже осознать сущность собственной деятельности, сформулировать ее задачи и ключевые параметры. На этом этапе очень эффективной оказалась простейшая визуализация процессов в виде блок-схем. Такое представление интуитивно понятно интервьюируемым с практически любым уровнем подготовки.
Стоит отметить, что мы часто сталкиваемся с ситуацией, когда в ведомствах процессы фактически еще не сформировались — есть только набор операций, которые пользователи не могут однозначно выстроить в цепочку. Когда процессы незрелые, не имеет смысла закладывать их в информационную систему. В таких случаях мы предлагаем более простые, иногда даже локальные (именно локальные, а не лоскутные) решения для автоматизации рутинных операций пользователей. Основные выгоды при этом:
• у пользователей освобождается время на продумывание и построение процесса;
• пользователи на деле ощущают пользу автоматизации и начинают относиться к проекту с большим энтузиазмом.
3. Выявление основных объектов и проектирование реестров.
Анализируя процессы (если они реально сформированы в ведомстве), определяем основные объекты, с которыми ведется работа. Характеристики таких объектов будут храниться в реестрах. Все типы реестров должны подчиняться следующим одинаковым правилам:
• способ поступления данных в систему;
• единые статусы для всех значений реестров;
• работа с документами, подтверждающими значения характеристик;
• работа с комментариями от владельцев информации.
Если система разрабатывается для регионального органа власти, то согласование типов и характеристик реестров с федеральным уровнем в разы упрощает дальнейшее расширение системы.
4. Описание процессов <4о Ье», или как они будут реализованы в системе.
Приступаем к описанию архитектуры системы, вернее адаптации типовой архитектуры под конкретную отрасль. На этом этапе появляется схема архитектуры будущей системы для согласования с участниками проекта. Процессы, которые списали с пользователей на одном из предыдущих этапов, переносим в формат информационной системы — рисуем процессы так, как они будут протекать после внедрения информационной системы.
5. Проверка модели <4о Ье».
Необходимость проверки во многом зависит от планов компании-разработчика на создаваемую систему. Если система позиционируется как продукт, который будет внедряться в других регионах в аналогичных ведомствах, то проверка смоделированных процессов на сходство с процессами органов власти других регионов обязательна.
No. 6 (54) 2014
Если же система разрабатывается под конкретного заказчика и в рамках одного проекта внедрения, то команда разработки может пропустить проверку. Однако с точки зрения федеральных органов, ответственных за информатизацию услуг, этот этап крайне важен и гарантирует сходство архитектуры систем на региональном уровне.
6. Определение постоянных и переменных характеристик для записей разных типов.
Характеристики, значения которых изменяются от процесса к процессу или от региона к региону, в архитектуре системы выносятся в настройки, адаптируемые под конкретный процесс, отдел или ведомство. Постоянные характеристики процесса становятся характеристиками соответствующего типа записи.
7. Анализ расчетных методик.
Расчетно-аналитические инструменты,
основанные на методиках, нужно проанализировать и соотнести с конкретным этапом оказания услуги.
8. Проектирование региональных порталов и аналитических приложений.
Поступление входных данных через порталы должно являться точкой запуска одного или нескольких процессов предоставления услуг на BPM уровне системы. Аналитические приложения для руководителей разных уровней агрегируют данные всей системы и обеспечивают возможность постоянного мониторинга процессов оказания услуг.
Заключение
Прикладная методика проектирования позволяет создать информационную систему, отвечающую основным принципам системного подхода. Так, процессные приложения, интегрированные в систему и спроектированные в ее рамках, позволяют получить синер-гический эффект от их внедрения, поскольку охватывают помимо основных процессов оказания государственных и муниципальных услуг еще и коммуникации между отделами.
Единство архитектуры на различных уровнях ведомства и в различных регионах
являются реализацией принципа иерархичности. Типовые интерфейсы, заложенные в систему на этапе проектирования, выступают гарантом того, что интеграция систем разных ведомств и уровней пройдет без ущерба для архитектуры систем.
Принцип обратной связи при проектировании информационной системы реализуется за счет модульности архитектуры и наличия гибких настроек. Эти свойства позволяют вносить корректировки в систему в зависимости от отзывов пользователей в ходе опытной эксплуатации. Модульная архитектура необходима еще и потому, что нормативно-правовая база оказания государственных и муниципальных услуг постоянно меняется, заставляя меняться и отдельные параметры информационного решения.
Предлагаемая нами методика позволяет не только получить на выходе архитектуры систему, решающую текущие острые проблемы информатизации органов власти в сфере государственных или муниципальных услуг, но и отвечающую задачам Программы [3] по следующим пунктам:
• автоматизация всего процесса оказания услуги, а не его отдельных операций;
• сквозная автоматизация, учитывающая взаимодействие участников процесса оказания государственной или муниципальной услуги;
• возможность использования межведомственных информационных ресурсов;
• возможность модульного масштабирования и приведения систем всех ведомств к единому архитектурному стандарту.
Внедрение системы с универсальной модульной архитектурой позволяет органам власти не только сократить расходы бюджетных средств по сравнению с внедрением решений, отличающихся архитектурно, но и распределить расходы во времени, выбирая минимально необходимый на текущий момент набор модулей реестровых и процессных уровней и в дальнейшем дополняя его желаемыми аналитическими надстройками и портальными решениями.
№ 6 (54) 2014
А для компаний-разработчиков благодаря предложенной архитектуре значительно снижаются затраты на поддержку и масштабирование продуктовой линейки.
Список литературы
1. Стратегия развития информационного общества в Российской Федерации от 7 февраля 2008 г. № Пр-212 // Российская газета. 2008. 16 февраля. № 4591.
2. Федеральный закон № 210-ФЗ от 27 июля 2010 г. // Российская газета. 2010. 30 июля. № 5247.
3. Государственная программа Российской Федерации «Информационное общество (2011-2020 годы)»: распоряжение Правительства РФ от 20 октября 2010 г. № 1815-р с изменениями от 18 мая, 2, 30 декабря 2011 г., 5 мая, 15 августа, 10, 27 декабря 2012 г., 20 июля 2013 г. // Российская газета (Интернет-портал). 2013. 29 июля.
4. Распоряжение Правительства Российской Федерации № 2516-р от 25 декабря 2013 года об утверждении Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде // Российская газета (Интернет-портал). 2013. 30 декабря.
5. Распоряжение Правительства Российской Федерации № 1163-р от 15 августа 2003 года об утверждении Программы социально-экономического развития Российской Федерации на среднесрочную перспективу (2003-2005 гг.) // Российская газета (Интернет-портал). 2003. 1 сентября.
6. Распоряжение Правительства Российской Федерации № 1244-р от 27 сентября 2004 года об утверждении Концепции использования информационных технологий в деятельности федеральных органов государственной власти до 2010 г. // Российская газета (Интернет-портал). 2004. 7 октября.
7. Распоряжение Правительства Российской Федерации № 1789-р от 25 октября 2005 года об утверждении Концепции административной реформы в Российской Федерации в 2006-2008 гг. и соответствующий план мероприятий // Российская газета (Интернет-портал). 2009. 24 июля.
8. ГОСТ Р 52294-2004 «Информационная технология. Управление организацией. Электронный регламент административной и служебной деятельности. Основные положения». Приказ Фе-
дерального агентства по техническому регулированию и метрологии Российской Федерации № 138-ст от 29 декабря 2004 г.
9. Филенко Е. Н. Электронные административные регламенты: проблемы реализации в документа-ционном обеспечении государственного управления // Делопроизводство. 2009. № 4.
10. Халл Элизабет, Джексон Кен, Дик Джереми. Разработка и управление требованиями: практическое руководство пользователя. Springer Science+Business Media, 2005. — 230 c.
11. Грекул В. И, Денишенко Г. Н, Коровкина Н. Л. Проектирование информационных систем. М.: Интернет-университет информационных технологий, 2005. — 304 с.
12. Смирнова Г. Н, Сорокин А. А, Тельнов Ю. Ф. Проектирование экономических информационных систем. М.: Финансы и статистика. 2001. — 512 с.
13. Петрова Е. А. Зарубежный опыт информатизации и особенности его реализации в России // Волгоградский государственный университет. Фундаментальные исследования. 2007. № 11.
14. Мельникова Е. Н. Экономическая эффективность информационных проектов для органов государственного регионального управления // Вестник ВолГУ. Серия 9. 2011. № 9.
15. Квятковский К. И, Шуршаев В. Ф. Проектирование информационных систем для органов государственной власти // Вестник АГТУ. Серия: Управление, вычислительная техника и информатика. 2011. № 1.
References
1. Strategija razvitija informacionnogo obshhestva v Rossijskoj Federacii ot 7 fevralja 2008 g. No. Pr-212. Rossijskaja gazeta, 2008, 16 fevralja, no. 4591.
2. Federal'nyj zakon No. 210-FZ ot 27 ijulja 2010 g. Rossijskaja gazeta, 2010, 30 ijulja, no. 5247.
3. Gosudarstvennaja programma Rossijskoj Federacii «Informacionnoe obshhestvo (2011-2020 gody)»: rasporjazhenie Pravitel'stva RF ot 20 oktjabrja 2010 g. № 1815-r s izmenenijami ot 18 maja, 2, 30 dek-abrja 2011 g., 5 maja, 15 avgusta, 10, 27 dekabrja 2012 g., 20 ijulja 2013 g. Rossijskaja gazeta (Internet-portal), 2013, 29 ijulja.
4. Rasporjazhenie Pravitel'stva Rossijskoj Federacii № 2516-r ot 25 dekabrja 2013 goda ob utverzhde-nii Koncepcii razvitija mehanizmov predostavlenija
No. 6 (54) 2014
gosudarstvennyh i municipal'nyh uslug v jelektron-nom vide. Rossijskaja gazeta (Internet-portal), 2013, 30 dekabrja.
5. Rasporjazhenie Pravitel'stva Rossijskoj Federacii № 1163-r ot 15 avgusta 2003 goda ob utverzhdenii Programmy social'no-jekonomicheskogo razvitija Rossijskoj Federacii na srednesrochnuju perspe-ktivu (2003-2005 gg.). Rossijskaja gazeta (Internetportal), 2003, 1 sentjabrja.
6. Rasporjazhenie Pravitel'stva Rossijskoj Federacii № 1244-r ot 27 sentjabrja 2004 goda ob utverzhdenii Koncepcii ispol'zovanija informacionnyh tehnologij v dejatel'nosti federal'nyh organov gos-udarstvennoj vlasti do 2010 g. Rossijskaja gazeta (Internet-portal), 2004, 7 oktjabrja.
7. Rasporjazhenie Pravitel'stva Rossijskoj Federacii № 1789-r ot 25 oktjabrja 2005 goda ob utverzhdenii Koncepcii administrativnoj reformy v Rossijskoj Fed-eracii v 2006-2008 gg. i sootvetstvujushhij plan me-roprijatij. Rossijskaja gazeta (Internet-portal). 2009, 24 ijulja.
8. GOST R 52294-2004 «Informacionnaja tehnologija. Upravlenie organizaciej. Jelektronnyj reglament administrativnoj i sluzhebnoj dejatel'nosti. Osnovnye polozhenija». — Prikaz Federal>nogo agentstva po tehnicheskomu regulirovaniju i metrologii Rossijskoj Federacii No. 138-st ot 29 dekabrja 2004 g.
9. Filenko E. N. Jelektronnye administrativnye regla-menty: problemy realizacii v dokumentacionnom obespechenii gosudarstvennogo upravlenija. De-loproizvodstvo, 2009, no. 4.
10. Hall Jelizabet, Dzhekson Ken, Dik Dzheremi. Razrabotka i upravlenie trebovanijami: prak-ticheskoe rukovodstvo pol'zovatelja. Springer Science+Business Media, 2005. 230 p.
11. Grekul V. I., Denishenko G. N., Korovkina N. L. Pro-ektirovanie informacionnyh sistem. M.: Internet-uni-versitet informacionnyh tehnologij, 2005. 304 p.
12. Smirnova G. N., Sorokin A. A., Tel>nov Ju. F. Proek-tirovanie jekonomicheskih informacionnyh sistem. M.: Finansy i statistika, 2001. 512 p.
13. Petrova E. A. Zarubezhnyj opyt informatizacii i osobennosti ego realizacii v Rossii. Volgogradskij gosudarstvennyj universitet. Fundamental'nye issledovanija, 2007, no. 11.
14. Mel'nikova E. N. Jekonomicheskaja jeffektivnost' informacionnyh proektov dlja organov gosudarstvennogo regional'nogo upravlenija. Vestnik VolGU, Serija 9, 2011, no. 9.
15. Kvjatkovskij K. I., Shurshaev V. F. Proektirovanie informacionnyh sistem dlja organov gosudarst-vennoj vlasti. Vestnik AGTU, Serija: Upravlenie, vychislitel'naja tehnika i informatika, 2011, no. 1.
K. Kutikova, Postgraduate Student, Saint-Petersburg State University, kkutikova@yandex.ru N. Iliyna, Product Manager, LLC «ISM», Moscow, ni.septima@gmail.com
Applied method for government and municipal services information system development
The article is devoted to problems of government and municipal services information system development. The main objective is to develop the architecture meeting number of requirements: the architecture should include techniques for resolving not only present, but also perspective problems of the sphere or department; the module for data communication with external systems should be a part of the architecture; the architecture should be independent of department's government power level, business objects on each power level of one sphere should be the same; business process automation should be architectural key element inspite of calculations automation; the architecture needs data warehouse development given basic relation database principles and BI systems data transfer.
Taking the quantity of departments and services into account, development of the architecture according the requirements above needs department team-work. The information system architecture based on experience of rate regulation informatization was offered by the authors. The information systems consists of four levels: Master Data Management level includes lists of basic objects of the sphere; Business Process Management level allows to get system configuration for different parts of business process integrating; Applied Applications for calculations automation and analysis; Portal and Business Intelligence Applications provides data transfer interface for communication with clients.
Actions needed for such information system architecture development in other sphere were described by the authors as list of government system engineering methods.
Keywords: universal system architecture, information systems, applied method for system development, informatization, government and municipal services, architecture requirements.
