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

Разбить на страницы

Показывать лекцию целиком

Особенности Архитектуры электронного правительства по сравнению с Архитектурой предприятия

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

Вспомним традиционное разбиение архитектуры на представления или частные архитектуры (домены), такие как бизнес-архитектура, архитектура информации, архитектура приложений и технологическая архитектура. Государство в целом и отдельные ведомства, на самом деле, имеют много общего, когда мы рассматриваем "нижние" уровни: инфраструктуру, вычислительные платформы и сети. Эти базовые уровни не несут и не отражают специфику, связанную с логикой деятельности организации и выполнения функций и бизнес-процессов. Однако очевидные различия с коммерческими предприятиями обнаруживаются по мере того, как мы рассматриваем "более верхние" слои стека информационных технологий, которые связаны с прикладными системами для исполнения конкретных государственных функций. Государственные ведомства отвечают за реализацию характерных для государства функций, и среди этих функций можно найти лишь небольшое число параллелей и аналогий с коммерческими организациями. Государственные ведомства также внедряют такие корпоративные системы, как системы управления ресурсами предприятия (ERP) или системы управления отношениями с клиентами, т.е. гражданами и бизнесом (CRM). Но даже при условии, что эти системы реализуют аналогичные функции, что и в бизнес-среде, реализация их в государственных ведомствах сильно отличается.

Если говорить об отличиях, связанных с выделением отдельных представлений (или доменов) в описании Архитектуры электронного правительства, то многие методики особо выделяют некоторые области, которые не всегда актуальны для архитектуры уровня предприятия.

В качестве примера можно привести концепцию Архитектуры электронного правительства Gartner [9.9], которая выделяет следующие представления:

интерфейс;

бизнес-архитектура (функции);

данные;

прикладные системы;

общие сервисы;

интеграция;

инфраструктура.

Это условно показано на рис. 7.1 в виде "пирамиды". Все перечисленные области Архитектуры электронного правительства обеспечивают основу использования информационных технологий в организациях. Архитектура на уровне государства в целом или на уровне отдельного ведомства должна быть дополнена структурами управления и набором процессов, которые ее поддерживают и обеспечивают, т.е. Архитектурой операций или Процессами управления Архитектурой и ИТ.

(рис 7.1) Концептуальная архитектура электронного правительства

Заметим, что данная концептуальная архитектура электронного правительства Gartner была опубликована еще в 2001 году и носит достаточно "традиционный" характер. В курсе "Архитектура предприятия" мы описывали несколько иную методику Gartner Group для описания архитектуры предприятия, которая впервые была опубликована в 2002 году. Она также применима к электронному правительству, и чуть позже мы рассмотрим особенности использования этой обновленной методики в отношении электронного правительства.

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

Рассмотрим более подробно особенности архитектуры электронного правительства в целом и отличительные черты отдельных доменов (областей) этой архитектуры.

Федеративная или централизованно-децентрализованная модель архитектуры

Одной из центральных характерных принципов реализации архитектуры электронного правительства является федеративная или централизованно-децентрализованная модель.

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

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

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

Как справедливо отмечено в [9.10], два фактора являются обязательными для успеха федеративного принципа реализации архитектуры, который, с нашей точки зрения, является единственно возможным для крупных государственных структур управления:

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

централизованные механизмы финансирования инфраструктурных проектов, которые требуются для реализации общих компонент федеративной архитектуры.

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

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

системы, обеспечивающие общие сервисы (базовые компоненты) (например, общий сервер электронных форм документов, общие сервисы безопасности, каталоги с информацией о государственных служащих, платформа для оплаты государственных услуг и т.д.);

прикладные системы, специфические для реализации конкретных функций и услуг.

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

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

хорошо определенная архитектура;

общие методики;

общие форматы и схемы данных.

Уровень интерфейса с клиентами

Характерной особенностью государства является обеспечение множественных каналов взаимодействия граждан и бизнеса с государством. По крайней мере, государство в силу политических причин обязано поддерживать традиционные каналы: физические офисы государственных ведомств, куда граждане могут прийти; телефон, обычная почта, а также новые каналы, связанные с возможностями Интернета или мобильных коммуникаций. Уровень интерфейса позволяет отделить бизнес-логику от интерфейса и позволяет иметь доступ к одной и той же бизнес-логике, используя различные устройства. При этом процесс реализации государственной услуги в форме реального выполнения каких-то административных регламентов внутри ведомств остается неизменным независимо от канала доступа.

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

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

Особенности архитектуры государственных функций (бизнес-архитектуры)

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

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

Успешная реализация принципов электронного правительства требует проведения работ по реструктуризации выполнения функций органами государственной власти и управления на уровне процессов и административных регламентов.

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

Тенденция использования функционального взгляда на описание деятельности государства является достаточно новой, по крайней мере, для России. Тем не менее, в этом направлении многое сделано в рамках методологий описания архитектуры электронного правительства в таких странах, как США, Германия, Великобритания.

Более детальный анализ процессов предоставления государственных услуг позволяет выявить следующее:

Большое количество аналогичных или очень близких по формам реализации услуг, предоставляемых различными ведомствами. Например, в Германии почти 3/4 всех услуг федерального правительства (73%) принадлежат к услугам трех типов: "Сбор, обработка и предоставление общей и специализированной информации", "Общие процедуры обработки заявлений, поступающих в государственные ведомства", "Процедуры оказания содействия и помощи";

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

Все это создает предпосылки для существенной экономии и достижения синергетического и интеграционного эффекта при реализации проектов электронного правительства за счет внимания к так называемым общим сервисам, таким как общая платформа для электронных платежей, сервер государственных электронных форм документов или сервисы безопасности. В архитектуре электронного правительства Германии эти общие сервисы получили название базовых компонент (модулей) и сервисов типа "один на всех".

Архитектура общих сервисов

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

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

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

Общим сервисам уделяется существенное внимание в методике описания архитектуры электронного правительства Gartner, а также в таких методиках, как SAGA Федерального Правительства Германии и e-GIF Правительства Великобритании.

Когда мы говорим об общих сервисах (или компонентах), то можно выделить:

централизованно спроектированные, но внедряемые локально общие сервисы;

централизованно спроектированные и централизованно внедряемые общие сервисы.

При этом можно назвать две крупные категории общих сервисов [9.11]:

Сервисы, связанные с реализацией процессов. Эти сервисы обеспечивают некоторые общие процессы и функции, реализуемые ведомствами, например, публикация информации на портале, управление финансами, управление персоналом, закупки, а также общие для них технические функции, такие как сервисы безопасности и т.д.;

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

Ниже приведен список сервисов и прикладных систем, которые относятся к первой из этих категорий (реализация процессов) и которые являются кандидатами на общие сервисы.

Информационное взаимодействие с гражданами и бизнесом:

Сервис правительственного портала. Это могут быть такие централизованные сервисы как выполнение полнотекстового поиска, доступ к разделам портала для различных ведомств в целях его информационного наполнения и т.д.;

Сервис управления контентом. Это может быть система, обеспечивающая единство процессов создания и обновления информации для порталов и сайтов государственных ведомств в среде Интернет и Интранет, что обеспечит необходимую стандартизацию в процессах публикации и внешнем виде документов, таких как пресс-релизы, тексты выступлений официальных лиц, интервью, фотографии и т.д.;

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

Транзакционные процессы:

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

Процессы поставок:

Системы электронных закупок. Эта система может обеспечивать все этапы процесса закупок продуктов и услуг в интересах ведомств с обеспечением реализации всех необходимых правил и законов;

Управление складскими запасами.

Корпоративные процессы:

Финансовые и бухгалтерские системы;

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

Системы управления персоналом;

Системы обучения персонала.

Специализированные процессы:

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

Следующие общие сервисы и системы можно отнести к категории обеспечивающих:

Многократно используемые инфраструктурные компоненты:

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

Сервисы каталогов. Этот сервис может обеспечивать, например, единый, основанный на стандарте X.500 каталог с адресной информацией, телефонами, адресами электронной почты служащих и т.д. в интересах всех государственных ведомств;

Сервис безопасности данных. Этот сервис, например, может предоставлять общие интерфейсы для реализации безопасного, контролируемого (в смысле мониторинга и аудита) и конфиденциального информационного обмена как между гражданами и бизнесом с государством, так и ведомств между собой. Он может быть реализован в форме виртуального почтового офиса, который обеспечивает шифрование и дешифрование электронных сообщений, проверку и генерацию цифровой подписи, аутентификацию на основе различных идентификационных данных, простановку на электронных документах "штампов" со временем наступления тех или иных событий, проверку сообщений на наличие вирусов.

Информационные сервисы:

регистр населения;

регистр хозяйствующих субъектов;

регистр объектов недвижимости;

земельный кадастр;

геоинформационные системы;

системы поддержки принятия решений.

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

Для успеха в реализации общих сервисов государство должно учитывать следующие четыре фактора:

Как выбрать и обосновать реализацию тех или иных сервисов в качестве общих?

Какую модель выбрать для реализации общих сервисов (организационные и прочие вопросы)?

Как обеспечить переход ведомств на использование общих сервисов?

Как обеспечить процессы улучшений в реализации и использовании общих сервисов?

Для ускорения процессов использования общих сервисов государство, ведомства и поставщики соответствующих сервисов могут придерживаться следующих рекомендаций:

продвижение общих для государства (региона) стандартов на электронные сообщения и документы (например, в форме утвержденных XML-схем);

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

использование принципов сервис-ориентированной архитектуры для построения прикладных систем в форме многократно используемых модулей;

использование стандартов web-сервисов;

принятие единых стандартов безопасности на информационный обмен;

использование единых методик моделирования административных и бизнес-процессов. Эти модели сделают понятными и явными связи между ведомствами и обеспечат основу для использования общих сервисов.

Общие сервисы являются первыми кандидатами на аутсорсинг этой части государственной инфраструктуры ИКТ.

Особенности домена данных в архитектуре электронного правительства

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

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

Дело в том, что ключевые государственные информационные системы должны эксплуатироваться десятилетиями, в то время как цикл использования информационных технологий и отдельных продуктов измеряется годами. Персональные компьютеры устаревают за 3 года; для таких бэк-офисных систем, как базы данных, жизненный цикл составляет 2-5 лет (после чего требуется сложный процесс обновления); языки программирования и другие элементы системной архитектуры (клиент/сервер, web-браузеры) "живут" примерно 10 лет. Напротив, в соответствии с законодательством, требуемый срок хранения данных по персоналу составляет 75 лет, а некоторые данные вообще должны храниться вечно.

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

К счастью, в настоящее время имеется консенсус по поводу лучшего способа обмена информацией – это XML. Можно сказать более того: XML является основой представления процессов, услуг и документов электронного правительства, потому что:

он является открытым: им "не владеет" ни одна организация;

он является "прозрачным" в том плане, что может читаться людьми и машинами;

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

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

Особенности архитектуры интеграции электронного правительства

Сложность проблемы интеграции информационных систем трудно переоценить. По оценкам аналитической компании ZapThink, до 70% процентов ИТ-бюджетов сегодня тратится на решение вопросов интеграции. При этом количество неудачных интеграционных проектов превышает количество успешных. Так, по оценкам Forrester Research, только 35% проектов по интеграции завершается в срок и в соответствии с бюджетом [9.13].

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

Поэтому явное выделение в архитектуре электронного правительства в качестве отдельного представления (домена) архитектуры интеграции (включая архитектуру программного обеспечения промежуточного слоя) носит обоснованный характер.

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

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

Этот подход обеспечивает быструю реализацию общих для правительства соответствующего уровня процессов без необходимости отдельным ведомствам отказываться от своих имеющихся систем и менять их на новые, "великие и идеальные" системы, разрабатываемые централизованно. Это также уменьшает требования, которые предъявляются к государственным служащим и ИТ-специалистам с точки зрения обязательного понимания в деталях общей картины всех государственных информационных систем для реализации новых сервисов в электронной форме.

Большое количество стран на национальном уровне пошли именно по этому пути и создали соответствующую основу архитектуры интеграции в форме инфраструктуры, для которой используются в разных странах такие названия, как "правительственный шлюз" (Великобритания, Чехия, Болгария Румыния), "Брокер Государственных Сервисов" (PSB – Public Services Broker) в Ирландии и т.д. По большому счету, все эти решения основываются на принципах сервисной шины (в терминологии сервис-ориентированной архитектуры), на использовании интеграционного ПО пересылки сообщений (MOM – Message Oriented Middleware), согласованных схемах XML-сообщений.

Дополнительную информацию по архитектуре интеграции электронного правительства вообще и по ее практической реализации в Великобритании можно найти в [9.14].

Особенности процесса реализации архитектуры электронного правительства

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

Определенную помощь оказывает разбиение этого сложного процесса на три отдельных, но взаимосвязанных этапа [9.15]. Эта условная схема представлена на рис. 7.2.

(рис 7.2) Этапы реализации Архитектуры электронного правительства

Заметим, что хотя этапы логически представлены в последовательной манере, на практике каждый из них начинается и реализуется еще до окончания предыдущего. Эти три этапа условно можно назвать так:

фаза построения основ;

фаза создания общих правительственных информационных систем (в английском языке используется термин "корпоративная фаза" – Enterprise phase);

фаза реализации специфических для ведомств и агентств проектов и систем.

Фаза построения основ состоит в создании общей для большинства ведомств инфраструктуры электронного правительства, на которой, собственно говоря, и базируются соответствующие прикладные системы. Практика показывает, что на этом этапе еще отсутствует целостное представление об Архитектуре электронного правительства. Отдельные ведомства сосредоточены на реализации того, что называется Технологическая архитектура.

Фаза построения основ включает создание следующих элементов:

вычислительная инфраструктура: центры обработки данных, серверы, сети, настольные системы и т.д.;

коммуникационная инфраструктура для передачи данных, голоса, видео, ТВ;

основные сервисы, обеспечивающие продуктивность работы персонала: текстовые редакторы, электронная почта, телефонная связь, удаленный доступ и т.д.;

политики, процедуры и стандарты (как внутренние для ведомств, так и общие для правительства соответствующего уровня в целом), которые описывают то, как обеспечиваются, поддерживаются, применяются, защищаются, оцениваются системы и сервисы. Например, это такие аспекты, как соглашения об уровне обслуживания, управление отношениями с клиентами (гражданами), процессы закупок, управление ИТ-активами, структуры управления и контроля и т.д.;

реорганизация департаментов ИТ, реинжиниринг процессов работы ИТ-департаментов, обеспечение их персоналом, обучение, удержание и поиск новых кандидатов, стратегия в области сорсинга (использование внутренних ресурсов или аутсорсинг), стратегии в области покупки консультационных услуг и т.д.

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

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

Примерами систем, которые создаются на этой фазе, являются:

финансово-бюджетные системы;

геоинформационные системы;

центральные регистры и кадастры (населения, собственность, земля).

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

На фазе реализации специфических для ведомств и агентств проектов и систем создаются системы, обеспечивающие реализацию функций отдельных ведомств и агентств. Это системы, реализующие совершенно конкретные для ведомств функции. Именно на этом этапе проводится основная работа по разработке архитектуры отдельного ведомства (в нашем понимании "Архитектуры предприятия"), которая должна строиться с учетом общих архитектурных решений, принятых на уровне правительства в целом. То есть, решения и проекты, реализованные на предыдущих двух этапах, являются основой и оказывают существенное влияние на характер работ, выполняемый ведомствами на этой фазе.

Страницы: