3. Системный подход

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

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

Проверим…

1. Первый шаг системного подхода:

Учесть все внешние и внутренние факторы влияния на систему

А с чего обычно практики начинают решение новой проблемы?

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

Чем это отличается от системного подхода?

Название и тем, что практики не любят делать это письменно.

Предостережение:

Эффект от учета факторов должен превышать расходы на их учет

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

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

Правило Романа Фельдмана (SAP):

Учесть все, что нужно, но как можно меньше.

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

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

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

Произведение этих величин дает вклад фактора в эффект системы.

Эффект = Важность х Оценка

Полный эффект системы находится как сумма указанных произведений по всем факторам. Пункты 1-4 дают до 50% возможного эффекта решения.

Вывод:

Системным подходом владеет людей больше,

чем людей про это знает …

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

Теория увеличивает потенциал последних, но только если они есть.

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

Системный подход – это здравый смысл формализованный в теории

P.S. 50% для большинства практических задач – немало и на первых порах достаточно.

Но, все таки, что нужно для того, чтобы приблизиться к 100%?

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

4. Пример создания информационной инфраструктуры на основе системного подхода

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

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

но неудовлетворительно решали задачи интеграции информации

Основная цель создания информационной инфраструктуры организации интегрировать (связать) существующие программы:

• Через центральный сервер

• Напрямую

Проблемы ведущие к необходимости интеграции:

1. Повторный ввод данных разными пользователями в разных точках организации.

2. Повторяемость запросов на данные от разных пользователей.

3. Большое количество пользователей системы (несколько тысяч-десятков тысяч).

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

4. Необходимость совместного использования существующих автономных решений.

5. Постоянные изменения «правил игры», которые требуют централизованного корректирования программного обеспечения у многих (или всех) пользователей.

Для преодоления подобных проблем около 40 лет назад была разработана идеология ERP - систем (Enterprise Resource Planning - планирования ресурсов предприятия) управления ресурсами предприятия

ERP – системы (например SAP) обеспечивают интеграцию:

1) людских ресурсов

2) информации

3) данных

4) процессов

При выборе конкретного типа ERP – системы выдвигают требования к:

• Функциональности

• Надежности

• Унификации

• Масштабирования

• Простоты модификации и т.д.

• А главное, чтобы поставщик технологии не исчез с рынка в середине жизненного цикла системы, оставив ее без техподдержки.

Именно так, в свое время, Министерство обороны выбрало технологию SAP, которая охватывает более 50% мирового рынка ERP – систем.

Основные цели проекта

• Обеспечение руководства достоверной информацией

• Достижение прозрачности деятельности

• Усовершенствование структуры органов управления

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

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

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

Для иллюстрации сложности информационных взаимосвязей, и соответственно уровня сверхвысоких требований к качеству работы телекоммуникационной составляющей Информационной инфраструктуры,

Перечень функциональных подсистем АС УОР:

• недвижимость;

• обеспечение жильем;

• бюджет и финансы;

• кадры и орг.структура;

• МТЗ (логистика);

• заработная плата;

• техническое обслуживание и ремонт (ТОРО);

• правовое обеспечение;

• оборонное планирование;

• поддержка принятия решений;

• классификация и кодирование;

• обмен информацией.

• медицина;

• образование;

• наука;

• международное сотрудничество;

• ревизионная деятельность.

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

В качестве потребителей (пользователей) в проект вовлечены практически все подразделения МОУ и ГШ.

Необходимым условием создания такой сложной информационной инфраструктуры является четкая

организационная структура проекта:

Включает Совет управления проектом, исполнительный и Оперативный совет, в состав которых входят представители от Заказчика, Разработчика и поставщика технологии SAP

Непосредственным выполнением работ занимается оперативный совет, который включает Рабочие подгруппы

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

Стороны проекта (или их представители)	Умения и знания	Время ввода в строй
Пользователь	Знает что надо. Не знает как сделать	0,5 – 1 год
Разработчики (консультанты)	Знает как сделать. Не знает – что.	3 – 5 лет
центр Внедрения	Знает чуть-чуть что и чуть-чуть как. 1. Налаживает диалог Пользователя и Разработчика; 2. Контроль Разработчика. 3. Тех.помощь пользователю.	1,5 – 2 года

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

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

Структура АС УОР включает:

• ЦК - центр коммутации (продуктивный сервер)

• АТК (автоматизированные технологические комплексы)

включают АРМ – автоматизированные рабочие места пользователей по функциональным подсистемам АС УОР

На 3-х уровнях (в/ч, командования-виды, МОУ-ГШ)

• ЦВ (центр внедрения).

Как это все выглядит

• Серверное оборудование

• Системы хранения данных

• Ленточные системы хранения данных

• Серверный комплекс Центра коммутации

• Серверный комплекс Центра внедрения

Как объдиняются и разделяются сервера

Зачем?

Чтобы разместить все функциональные подсистемы по отдельным логическим серверам?

Отчасти да, но в основном

каждый логический сервер занимает полный комплект подсистем.

Главное, что на разных логических серверах

ERP система «живет» в разные периоды своего развития:

• разработка,

• обеспечение качества,

• продуктивная эксплуатация.

Зачем? Для повышения качества.

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

Мандант включает:

• Репозитарий объектов (программы, таблицы и т.д.).

• Общие настройки.

• Специальные настройки (коды, словари).

• Данные прикладных программ.

• Данные о пользователях.

Для препятствия транзиту ошибок манданты не взаимодействуют между собой напрямую.

Коды и настройки отлаженные в манданте разработки можно переносить в продуктивный мандант, но прежде, чем это произойдет, они должны бать протестированы в манданте качества.

Ошибки обнаруженные в качестве устраняют только в разработке.

После этого тестирование повторяют и при положительном исходе

коды и настройки из разработки переносят в продуктив.

Чем сложнее система, тем тщательнее процедура тестирования.

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

Кто всем этим должен заниматься?

Разработчик?

Возможно, но если с ним что-нибудь случится, то где искать текущие результаты разработки?

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

Итак, Структура АС УОР включает:

• продуктивный сервер

• АТК

• ЦВ (центр внедрения). Сервер разработки. Тестирование, обучение и тех.поддержка пользователей.

Основная задача ЦВ на этапе разработки – техническая поддержка и контроль разработки.

Для техподдержки используется Call-Center.

В конечном счете Центр внедрения должен трансформироваться в центр компетенции, который для такой системы (в соответствии с мировым опытом может дать экономический эффект до 2 млн. долл. в год.

1. Снижки до 75% от стоимости лицензий.

2. Отказ от привлечения внешних консультантов (до 2 000 евро в день)

3. Обучение пользователей от 500 до 5000 долл. на 1 человека.

То, что мы рассмотрели в структуре АС УОР можно назвать:

• Централизованная система

Кроме того, предполагается наличие таких составляющих:

• Децентрализованные компоненты

• Мобильные компоненты

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

Создание КСЗИ (комплексной системы защиты информации) включает:

1. (12 мес.) Формирование общих требований к КСЗИ

2. (8 мес.) Разработка политики безопасности информации

3. (3 мес.) Разработка технического задания на создание КСЗИ.

4. (6 мес.) Разработка проекта КСЗИ. Введение КСЗИ в действие. Оценка защищенности информации

Для связи с другими ИАС (информационно-аналитическими системами) должны быть предусмотрены программно-аппаратные комплексы передачи закрытой информации.

Аутентификация пользователей осуществляется с помощью центра сертификации ключей.

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