А.Коптелов, О.Бейлезон, Компания IDS Scheer & Software AG
Бум в автоматизации государственного сектора наблюдается уже не один год, однако с точки зрения граждан эффекты от этой автоматизации пока не видны. И это связано с тем, что большинство ведомств автоматизируют свою внутреннюю деятельность, без учета автоматизации интерфейсов между собой и пользователями государственных услуг. Учитывая, что единой стратегии автоматизации государственного сектора на настоящий момент не существует каждое ведомство идет своим путем. И если на федеральном уровне можно встретить серьезные тиражируемые решения, то на уровне региональном каждое ведомство строит ИТ- ландшафт по-своему. Таким образом «зоопарк» информационных систем в одном регионе может достигать нескольких десятков, что делает их совместное использование достаточно сложным. Ведь каждая система имеет свою структуру хранения информации, свой интерфейс, свою платформу, при этом в момент разработки данных систем никто даже и не задумывался о требованиях к их интеграции с другими приложениями. Такие островки автоматизации дают решение отдельных внутриведомственных задач, но в целом повышение эффективности от их использования не видно на уровне сквозного межведомственного процесса предоставления государственных услуг.
Выходов из сложившейся ситуации несколько. Первый из них – разработать типовое решение по автоматизации государственных услуг и на его основе развернуть проект по их переводу на это решение. Неплохой подход, который может легко окупиться в масштабах всей страны, однако его масштабность и является его основным минусом. Практика показывает, что никакие масштабные межрегиональные и кросс-функциональные ИТ- проекты в государственном секторе пока положительно не завершались. Однако на верхнем уровне, решение о скорейшей автоматизации уже принято и сроки уже определены и закреплены нормативно, что требует от большинства регионов идти другим путем. Менее затратный и рискованный, а главное более быстрый путь заключается не в создании тиражировании специализированного решения для государственного сектора, а в создании «композитного» ИТ- решения на основе существующих в ведомствах приложений. Фактически можно обойтись автоматизацией межведомственного взаимодействия, оставляя при этом нетронутым внутреннюю автоматизацию отдельных ведомств. Несмотря на то, что это более реалистично, чем масштабная автоматизация, на этом пути препятствий тоже достаточно. И в первую очередь это ограничения связанные с межведомственным обменом информацией. Управления федеральных ведомств на региональном уровне руководствуются своими внутренними нормативными актами, в которых часто напрямую прописан запрет на передачу информации в смежные ведомства. И таких случаев десятки. Где то в рамках отдельного регламента, закрепляющего процедуры межведомственного взаимодействия часть барьеров можно нивелировать, однако в полном масштабе задачу беспрепятственного межведомственного обмена информацией еще предстоит решить на федеральном уровне.
Если тем или иным способом преодолеть организационные ограничения, то следующим вопросом, который будет необходимо решить, станет разрозненность платформ, технологий и форматов информации, которые существуют в ведомствах по факту. Именно для объединения этого «зоопарка» в композитное ИТ- решение и требуется интеграционный инструментарий (ESB) в котором каждая ведомственная система представляется в виде отдельного сервиса, который поставляет или потребляет определенную информацию, а разница форматов как раз и устраняется в данном инструментарии. Обеспечивая взаимосвязь между информационными системами, помимо интеграционного функционала востребована и функциональность автоматизации процесса (BPM), в рамках которой разрабатываются пользовательские формы, и осуществляется маршрутизация задач между ведомствами. Такое совместное использования функционала BPM и ESB позволяет в рамках одной технологической платформы обеспечить полный цикл автоматизации государственных услуг.
Фактически единая сервисная шина формируется на межведомственном уровне, воспринимая ведомства как отдельные организационные единицы. При этом сервис-ориентированный подход (SOA) в данном случае будет результативен, в части рассмотрения ведомства в виде набора сервисов с четким регламентом их использования. В такой архитектуре отдельные сервисы можно заменять без ущерба для основной системы. Например, если федеральное ведомство решит изменить логику своей работы, то это должно остаться незамеченным для других в части организации сквозных процессов.
Если посмотреть дальше, то можно рейтингованием выбирать наилучшие сервисы из различных регионов, что в свою очередь поможет тиражировать лучший опыт между ними. В случае изменений, которые столь часто происходят в наше время, сервисная шина позволит безболезненно перекидывать функции из одного ведомства в другое, сохраняя ранее сделанные инвестиции в их разработку. И самое интересное, что данный подход не привязан к определенному продукту, а лишь требует присутствия определенных компонентов в ИТ-решении, которые и обеспечивают «гибкость» создаваемому композитному приложению.
В первую очередь это портальное решение, используемое в качестве единой точки доступа для пользователей и сотрудников ведомств. Данное решение содержит информационные материалы и возможность заполнения исходных форм. Затем это интеграционная платформа (ESB), которая позволяет интегрировать «зоопарк» систем на уровне сервисов располагающихся в отдельных ведомствах. С портального решения осуществляется старт определенного экземпляра процесса, который тиражируется в интеграционном решении для нескольких ведомств. Далее информация по шине передается в отдельные ведомственные информационные системы в тех форматах, которые им понятны. Обратным потоком идет информация о статусах задач внутри ведомств, для отражения этой информации в портальном решении.
Для автоматизации «ручных» участков процесса используется BPM система, которая маршрутизирует поток заданий между пользователями, как в рамках одного ведомства, так и между ними. В результате такого подхода, создается ИТ- решение в основе которого заложена продуктивная платформа, которая в первую очередь связывает разрозненные компоненты в единое решение. При этом после внедрения платформы можно постепенно наращивать ее присутствие в ведомствах через вытеснение устаревающих собственных разработок. В рамках такого композитного решения должны максимальным образом использоваться существующие сервисы, причем их тираж между регионами может принести огромную экономию в масштабах всей страны. В отличие от разработки единого решения и тиража, второй путь позволяет осуществить «мягкий» переход от существующего зоопарка к единому ИТ - решению.
Но, так или иначе, с федерального уровня необходимо четкое указание, как строить автоматизацию на региональном уровне, иначе разношерстная автоматизация будет только усугубляться со временем. И очень жаль, что в настоящий момент пока нет такого четкого указания, поэтому большинство регионов идут своим путем, выбирая решения не на основе целевой архитектуры, а в соответствии с существующими потребностями, бюджетами и сроками.
Рассмотрим на примере одного из проектов, который выполнялся с использованием ESB и BPM решения архитектуру получаемого решения. В качестве пилотной услуги была выбрана комплексная услуга «Регистрация рождения ребенка». Услуга достаточно интересная в части автоматизации, с учетом того, что услуга содержит в себе несколько государственных услуг, и фактически закрывает весь цикл регистрации ребенка во всех органах власти. Проект интересен также тем, что в ходе его была выполнена автоматизация соответствующих услуг как минимум до 4-го уровня (а в некоторых случаях и до 5-го – с предоставлением результатов исполнения услуги в электронном виде). Итак, после рождения ребенка счастливый родитель имеет 2 возможности запросить у государства предоставление комплексной услуги «Регистрация рождения».
Первый путь традиционный – через личное обращение в органы ЗАГС, второй путь инновационный – заполнение электронного заявления на Портале государственных услуг. Но и в том, и в другом случае происходит одно и то же – инициация нового процесса комплексной услуги. И первым исполнителем комплексной услуги является орган ЗАГС. Услуга этого органа – регистрация новорожденного и выдача Свидетельства о рождении. После того, как первая услуга оказана, данные о заявителе передаются сразу в несколько ведомств: - в Пенсионный фонд РФ для получения номера СНИЛС (страховой номер индивидуального лицевого счета); - в страховую компанию обязательного медицинского страхования (СК ОМС) для выдачи полиса ОМС; - в Управление Федеральной Миграционной Службы (УФМС) для постановки отметки в паспорте и постановки на регистрационный учет; - и в Управление образованием (УО) для постановки в очередь на зачисление в дошкольные образовательные учреждения (ДОУ).
Каждое из этих ведомств имеет свою нормативную базу по получению и передаче информации в электронном виде, и в рамках данного проекта потребовалось учесть все требования ведомств, с чем успешно справилась интеграционная платформа. Правильное и своевременное исполнение предусмотренных законодательством процедур в рамках оказания государственных услуг обеспечил «движок» BPM, а контроль исполнения и сбор ключевых показателей для анализа взяла на себя подсистема контроллинга. Обязательным компонентом предоставления государственных услуг в электронном виде является возможность контроля статуса оказания услуги самим заявителем. И это требование также было реализовано на проекте – в портал госуслуг был встроен функционал «Личного кабинета», позволяющего отследить статус оказания комплексной услуги – а точнее, каждой входящей в нее услуги – по уникальному идентификатору обращения. При демонстрации статуса оказания услуги заявителю также предоставляется информация, «подсказывающая» ему, что ему нужно делать дальше: например, ожидать результата предоставления услуги в электронном виде (как в случае с ДОУ) или обратиться в соответствующий орган лично (как в случае с простановкой отметки в паспорте в УФМС).
На примере данной услуги можно понять, что даже применение лишь интеграционной схемы потребовало устранения множества организационных барьеров – региональные ведомства должны были договориться с федеральными о порядке передаче информации, использовании технических средств передачи и защиты данных, «утрясти» спорные моменты по ФЗ-152. Но после того, как это было сделано, перевод услуги в электронный вид превратился в задачу, типичную для организации, автоматизирующей процессы, и типовую для соответствующей интеграционной/BPM-платформы. Что лишний раз доказывает – не бывает неразрешимых задач, главное – найти правильный подход к решению.
Главная 
