понедельник, 21 октября 2013 г.

#egov 2.0 «à la russe» с точки зрения корпоративного архитектора

Данная статья обсуждает «Концепцию развития механизмов предоставления государственных и муниципальных услуг в электронном виде», опубликованную Министерством связи и массовых коммуникаций РФ (2013-10-16, http://minsvyaz.ru/ru/news/index.php?id_4=44086 ).

1   Резюме

"Концепция ..." представляет собой солидное обоснование для построения неплохой технической «потемкинской деревни».

2 Архитектурные проблемы

Системная эвристика в тему: «In architecting a new [software] program all the serious mistakes are made in the first day.»

2.1 Размах (scope)

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

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

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

2.2 Архитектура мыслится только для инфраструктуры

Современная корпоративная архитектура «расчленяется» на четыре части:
  1. бизнес архитектура
  2. приложения (архитектура ПО для специфики системы)
  3. архитектура данных
  4. техническая архитектура
Для успешного развития системы все четыре архитектуры обязаны составлять концептуальное единство (именно корпоративная архитектура обеспечивает это единство). Концепция же рассматривает только и частично техническую архитектуру.

2.3 Все еще говорим о документообороте

Документооборот охватывает только видимую часть «айсберга» бизнес-процессов организации и, таким образом, ограничен по потенциалу повышения эффективности. Весь развитый мир говорит о бизнес-процессах.

3 Организационные недочеты

Системная эвристика в тему: «If the politics don’t fly, the system never will.»

3.1 Снова министерство

Практика разработки ЭП одним из министерств приводит к конфликту интересов. Например, одновременно с опубликованием концепции «Минкомсвязи предложило потратить на модернизацию «Почты России» 145 миллиардов рублей. В ведомстве считают, что больше половины из этой суммы необходимо израсходовать на ремонт и модернизацию отделений. 25 миллиардов рублей предлагается потратить на обновление ИТ-систем…».

3.2 Совет главных конструкторов

Ну просто какой-то форум или клуб по интересам для людей из одной и той же отрасли. Кто будет выполнять его решения?

4 Предлагаемый подход

4.1 Архитектура
Изложена в следующих блогах:
  1. How many #entarch projects do you need in your #e-government & #e-governance initiative? -- http://improving-bpm-systems.blogspot.ch/2013/09/how-many-entarch-projects-do-you-need.html
  2. #e-government and #e-governance reference model #entarch #bizarch #apparch – в http://improving-bpm-systems.blogspot.ch/2013/10/entarch-e-government-and-e-governance.html

4.2 Управление построением ЭП

На встрече с Президентом РФ в ноябре 2009 г. министр информации, коммуникаций и искусств Сингапура Луи Так Ю не скрывал, что секрет успеха в создании электронного правительства (ЭП) кроется в централизации.

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

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

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

В дополнение к двум традиционным подходам по внедрению централизованного управления в области информационных технологий – «сверху вниз» и «снизу вверх» -- стал добавляться «профильный» подход (centre of excellence или competence centre). «Профильный подход» состоит в создании центра компетенции по определенной тематике, например, направления (FOSS), производителя ПО (Oracle, Microsoft), технологии и т.п. Так, повышенный интерес к BPM привел к рекомендациям по созданию соответствующего центра компетенции.

Какой из этих трех подходов наилучший – это зависит от конкретных условий. Если основным лимитирующим фактором внедрения ЭП является время, то требуется архитектурный подход:
  1. Создание небольшой архитектурной группы как ядра профессионального сообщества, объединяющего всех вовлеченных в ЭП архитекторов. 
  2. Анализ существующих разработок в области ЭП и принятие эталонной архитектуры ЭП, которая основывается на BPM, SOA и EA. 
  3. Быстрая реализация на основе эталонной архитектуры 2-3 функциональных прототипов для демонстрации (всем вовлеченным партнерам) использования BPM и SOA в органах государственной власти. 
  4. Создание на основе эталонной архитектуры платформы ЭП, состоящей из унифицированных архитектурных компонент. Некоторые из таких компонент поддерживаются своими центрами компетенции. 
  5. Проработка на основе эталонной архитектуры архитектуры решения для каждой услуги ЭП; постановка задач и координация работы выполняется архитектурной группой. 
  6. Управление портфолио проектов, включающих проекты по реализации решений, планы по развитию платформы ЭП и центров компетенции. 
  7. Создание и развитие экосистемы ЭП, постоянный обмен опытом и постепенное улучшение архитектуры ЭП. 
Отметим, что архитектурный подход органически сочетает преимущества остальных подходов:
  • проектирование сверху-вниз, 
  • реализация снизу-вверх, 
  • функциональная специализация в центрах компетенции. 
Вообще-то нужен «царь» по ЭП. 

Спасибо,
AS

Комментариев нет:

Отправить комментарий