Архитектура электронного правительства. Часть девятая - вводная для муниципалитетов

После большого перерыва начнем разбираться с муниципалитетами. В Российской федерации принято разделение на два типа муниципалитетов: муниципальные районы и муниципальные городские округа. Хотя на самом деле все гораздо сложнее. С муниципальными районами  все более или менее понятно, это сельские районы субъектов федерации, с небольшим населением (потому, что они сельские), часто с огромной площадью. А вот с городскими округами все сложнее. Это и, фактически, поселки, с количеством жителей до 50 тысяч и средние города, до полумиллиона жителей, и города-миллионники, в которых населения больше, чем в некоторых европейских государствах.

По закону перед всеми этими муниципалитетами поставлены одинаковые задачи, но, очевидно, что возможности по решению этой задачи у них совершенно разные. Соответственно подходы к архитектуре тоже будут разными.

Для больших городов, возможно, выгодней, с точки зрения управляемости и денег будет построение своего собственного сегмента СМЭВ, а для небольших городов, сельских районов однозначно выгодней во всех смыслах строить свои сегменты в рамках некоего ЦОД регионального уровня.

Архитектура электронного правительства. Часть восьмая – облака над поселком

Я решил специально остановиться на «облачном» вопросе. Не надо быть семи пядей во лбу для того, чтобы понять, что использование инструментов e-gov на уровне поселений, неважно первого типа или второго, будет минимальным. Причины этого вполне предсказуемые: лень, «отсутствие необходимости», ну и попросту сельским жителям сложно посетить сайт собственного поселения, да и у них свои заботы: корова недоена, уборка, посадка и т.д. Все это гораздо важнее, чем пнуть председателя сельсовета, чтобы он, наконец, вкрутил лампочку на фонарном столбе, если он – столб – вообще есть.

Вывод – разворачивать всю инфраструктуру, информационные системы - как минимум не выгодно, как с точки зрения денег, так с точки зрения трудозатрат. С минимальными потерями выйти из этой ситуации поможет парадигма облачных вычислений. Причем, именно с точки зрения оплаты за потребленные ресурсы. Вопрос теперь в том, где же взять это облако. Фактически это означает, что необходимо иметь облачные сервисы для субъекта федерации, которые будут обслуживать все поселения на территории (для примера: в Волгоградской области более 400 муниципальных поселений). Причем, подразумевая, что, потенциально, эти маленькие электронные правительства будут обрабатывать персональные данные, следует говорить о построении некоей смеси Government private cloud и Government public cloud, тут сложно говорить о терминологии. С одной стороны эти облака должны выдавать наружу внешние порталы поселений, с другой – они не должны выдавать беспрепятственно наружу системы обработки запросов граждан и внутренние порталы.

Построение такого облачного ЦОДа, с точки зрения первоначальных вложений, в глобальном смысле (не вдаваясь в особенности бюджетного устройства РФ), будет гораздо выгодней, чем развертывание 400+ отдельных серверов. Далее встанет вопрос в стоимости операционной деятельности. Боюсь, что такой ЦОД всегда останется дотируемым, даже если будет предоставлять услуги для поселений на возмездной основе. Тем не менее, стоимость операционной деятельности (ROI) облачного ЦОДа будет меньше совокупного ROI все поселковых серверов. Можно попытаться промоделировать все деньги, но я не буду делать этого в блоге J

Архитектура электронного правительства. Часть седьмая

Второе предложение – предложение для поселения второго типа. Поселение такого типа несколько больше по численности и, что важнее – население компактнее проживает, администрация больше. По сути дела, это чаще всего населенные пункты – районные центры.
Задач у таких администраций, по факту, несколько больше, и возможностей тоже больше. Исходя из всего этого предложение может иметь следующий вид:

Тем не менее, проблемы с кадрами в таких администрациях остаются (имеется в виду, что администрации не только не могут взять на работу ИТ специалиста, но и найти приходящего - сложно), поэтому необходимо предусматривать возможность передачи обслуживания инфраструктуры, приложений на сторону. Не только в чистый outsourcing людей, но и использовать IaaS и SaaS.
Применение промышленной CRM, как основы для построения системы обработки обращений граждан в данном случае уже становится оправданной.
Внутренний портал выполняет функции средств групповой работы, а также простейшей системы документооборота.
Внешний портал является как представительством администрации поселения в Internet, так и точкой входа в систему обработки обращений граждан.

Архитектура электронного правительства. Часть шестая.

Итак, начну с предложения муниципальному поселению первого типа. Для начала – что оно собой представляет – поселение первого типа. В терминах советской власти – это сельсовет. Сейчас это, фактически, от 3 до 5 человек во главе с выбранным начальником. Инфраструктуры чаще всего никакой, цели и задачи минимальны. Поэтому, даже минимальное предложение покроет все потребности. Но, тем не менее, это потребует от поселенческой администрации довольно больших, по их меркам, вложений в технику и ПО. В идеале все решение должно развертываться на одном серверном боксе, что по нынешним временам вполне возможно.
Так же следует учитывать практически абсолютное отсутствие в деревнях сколько-нибудь квалифицированных IT работников, поэтому решение должно предоставлять возможность публикации документов, обслуживание сайта и т.д., как минимум малоквалифицированному человеку. Именно поэтому, при наличии вменяемых каналов связи, имеет смысл говорить о выносе решения в «облако», т.е. либо использование IaaS, либо SaaS (а почему бы и нет?). Естественно, это возможно только при решении вопросов, возникающих на законодательном уровне.
Исходя из задач, предложение должно иметь следующий вид:

Следует иметь в виду, что система обработки обращений граждан в этом случае должна быть простейшей, не подразумевать под собой какой-то промышленной CRM.
Внутренний портал должен обеспечивать совместную работу специалистов администрации поселения: совместные календари, области документов, списки задач и т.д., так же внутренний портал должен предоставлять сервис персональных областей для работников администрации.
Внешний портал – это представительство поселения в Internet. Место публикации новостей, информации о поселении и т.д., а также входная точка для граждан в системе обработки обращений граждан.




Продолжение следует…

Архитектура электронного правительства. Часть пятая.

Несмотря на мой предыдущий пост и смотря на законодательство РФ, на мой взгляд, стоит разделять предложения по построению ЭП, классифицируя территориальные образования по уровню власти. Для РФ это будет (я не беру во внимание федеральный уровень власти):

• Муниципальное поселение
  
• Муниципальное образование (район субъекта федерации/ муниципальный городской округ)
  
• Субъект федерации
  

Перед каждым из уровней стоят свои задачи и у каждого из них есть свои потребности. Причем, на мой взгляд , также еще следует делить муниципальные поселения на два вида, и муниципальные образования так же на два вида.

Муниципальные поселения:

• Тип 1: сельские поселения в районах субъекта федерации
  
• Тип 2: городские и поселковые муниципальные поселения. Пример: г.Жирновск Волгоградской области.
  

Муниципальные образования:

• Тип 1: муниципальные районы и небольшие города подчинения субъекта федерации. Пример: Урюпинский район и г.Урюпинск (все таки столичный город, хоть и российской провинции) Волгоградской области.
  
• Тип 2: большие города подчинения субъекта федерации, столицы субъектов федерации. Пример: г. Волжский Волгоградской области, Тольятти, Самара, Волгоград и т.д.
  

К сожалению, я ,пока, не смог сформировать четкие количественные критерии, по которым можно отнести муниципальное поселение или образование к тому или иному типу. Думаю, что это будет очень трудно сделать.

Итак, в зависимости от ранжирования территориальное образование будет получать предложение различной «тяжести»: от самого легкого для муниципального поселения первого типа, до самого тяжелого для субъекта федерации.

Продолжение следует….

Архитектура электронного правительства. Часть четвертая - красочная

От общественно-политических изысканий перейдем к более приземленным - архитектурно-техническим.

На диаграмме представлена примерная архитектура, еще раз в кавычках, «электронного правительства».

А где же, спросите вы, система электронных государственных услуг, и всякие новые системы, если вдруг они понадобятся?
Все очень просто, отдельная система гоc.услуг – это фикция, она никому не нужна. Ведь гос.услуги, неважно каким образом они предоставляются, есть результат исполнения своих функций государственным органом. Соответственно за выполнение государственных услуг отвечают уже существующие наследованные системы, либо новые, которые будут создаваться для облегчения выполнения функций органа власти. А граждане будут отправлять запросы на получение услуги и отслеживать состояние заявки посредством цепочки [портал, соц. сервисы, система электронных коммуникаций] –> [шина данных и система исполнения бизнес-логики]->[наследуемые системы].

Продолжение следует....

Архитектура электронного правительства. Часть третья

Для многих становится открытием то, что правительство или администрация субъекта РФ не является одним юридическим лицом. Комитеты, управления, министерства, аппарат Главы (Президента) – все они являются отдельными юридическими лицами, со всеми вытекающими последствиями. Причем министерства финансов или управления или комитеты (в разных субъектах называются по разному, но название сути не меняет) – живут, чаще всего, совершенно отдельной жизнью, со своими маленькими ЦОДами, со своими немаленькими бюджетами на ИТ и т.д.

Продолжение следует…

Архитектура электронного правительства. Часть вторая – экономическо-политическая

Дальше перейдем от технических деталей к организационным. Вполне понятно и обоснованно, что обмен данными между различными ведомствами и, что подразумевается, между их информационными системами должен проходить в некоем стандартизованном виде. И тут (сюрприз, сюрприз!) сразу видно, что никаких стандартов нет. Логично поставить вопрос, кто будет делать стандарт, кто его должен соблюдать и кто за все это будет платить.

На федеральном уровне все более или менее понятно. А вот когда дело касается региональных властей - все не так прозрачно. В большей части субъектов федерации, по факту, нет органов, которые отвечают за стандартизацию. Либо их просто нет, либо они не дееспособны. Да, есть громкие названия, но часто у них нет ни соответствующих рычагов влияния, ни, что тоже довольно часто случается, желания что-то стандартизировать.

Вопрос – кто за все будет платить - не менее животрепещущий, и тут дело даже не в том, есть ли деньги или их нет. Экономически неэффективно строить инфраструктуру «электронного правительства» в каждом муниципальном районе, поселении или городе. Гораздо эффективней сделать некую общую инфраструктуру для субъекта федерации, где будут консолидированны все сервисы. И тут на сцену вступает закон 131-ФЗ и Бюджетный Кодекс Российской Федерации, которые прямо запрещают исполнять функции муниципалитетов за счет казны субъекта.

Каким образом сделать так , что бы не нарушать законы и все таки построить общую инфораструктуру сказать пока сложно. Вероятно необходимо оказывать услуги инфраструктуры на возмездной основе. Но вменяемых методик расчета стоимости этих услуг нет.

Продолжение следует….

Архитектура электронного правительства

Можно рассматривать электронное правителтьство как нечто эфемерное и не применимое к реальной жизни, или как просто рекламный слоган. На мой взгляд, ЭП стоит рассматривать как некую информационную среду, интергрирующую разнородные наследованные информационные системы. Ни для кого не секрет, что в РФ информатизация именно правительственных органов на урове субъекта федерации находится не на самом низком уровне. Да, не все области деятельности подверглись воздействию ИТ, но, например, такие области как исполнение бюджетов, социальная защита в части пособий и т.д., т.е. все то, что так или иначе связано с деньгами – попросту не может быть выполнен вручную.

Итак, какие же компоненты нам нужны для того, чтобы создать такую информационную среду, условно называемую «Электронным правительством». Все зависит от задач, которые предполагает исполнять эта система. Как ни напыщено это звучит, но основная задача электронного правительства – информирование граждан о том, как исполняются те или иные функции правительства. Если мы хотим информировать, то нам нужно что-то, что мы должны показывать. И это что-то является абсолютно разнородным. Вывод такой, что это задача для BI. Использование BI подразумевает под собой наличие некоего централизованного хранилища данных, на основе которых будет проихведен анализ и отображение интересующей граждан информации. Второй компонент – система, которая будет собирать разнородные данные из наследованных систем и наполнять наше хранилище. Это задача, возможно, для ESB (Enterprise Service Bus).

Продолжение следует.

Про электронное правительство

Рассматривая сейчас тему электронного правительства, по долгу работы, можно сказать следующее: в России и за ее рубежами абсолютно разный подход к этому делу. Даже в представительстве одной очень известной западной компании (моем нынешнем месте работы), взгляды сильно отличаются от того, что пропагандируют в Европе или в штаб-квартире.

Российские взгляды, как всегда, поражают своим гигантизмом. Под электронным правительством понимается нечто такое, что полностью покрывает область действия чиновника. Этакого многокомпонентного монстра, которого надо поставить сразу. Тут и внутренний и внешний порталы, документооборот, почта, система коллективной работы, сайт госуслуг и т.д. и т.п.

Западные взгляды одновременно проще и прагматичнее. Под электронным правительством понимается некий механизм взаимодействия между государством и гражданами, причем сейчас этот механизм сродни Web 2.0. Это форумы, социальные сети и сервисы и т.д. Все остальное – да, тоже имеет место быть, но не рассматривается как электронное правительство, а рассматривается как инструменты облегчения работы чиновника и как, в дальнейшем, инструмент для подготовки отчетов о деятельности правительства, которые предоставляются гражданам. То есть, вот она, информационная открытость в действии.

Последний день на госслужбе

28 января будет мой последний день на госслужбе. Прошло 14 с половиной лет на этой работе, всякое было… Пора внести перемены :)