Архитектурный подход к развитию ИТ-комплекса предприятия

Евтюшкин А.В.
доцент кафедры
"Системы управления бизнес-процессами".
Школа IT-менеджмента
РАНХиГС при Президенте РФ

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

Такие подходы создают для ИТ-директора ситуацию вечного цейтнота и перенапряжения, так как подталкивают к тому, чтобы решать задачи не столько важные, сколько срочные. Более конструктивно использовать архитектурный подход к развитию ИТ-комплекса предприятия.
Архитектурный подход в настоящее время достаточно глубоко разработан. Существует более десятка только основных методологий его применения , отличающихся различными способами представления архитектуры предприятия и глубиной ее детализации. Для практического использования годится, в сущности, любой из них, главное при этом – соблюдать последовательность и не выходить из принятой парадигмы.

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

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

Рис. 1. Архитектурный подход.

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

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

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

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

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

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

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

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

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

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

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

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

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

В Табл. 1 левая колонка «Деятельность» представляет собой примерный перечень видов деятельности предприятия. Приведенная структура видов деятельности относится к производственному предприятию. Инвариантным является перечень категорий деятельности:

• Производство.
• Логистика.
• НИОКР.
• Снабжение.
• Сбыт.
• Финансы.
• Управление.
• Обеспечивающая деятельность.

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

Приведенный перечень видов деятельности не является исчерпывающим и должен быть внимательно проанализирован и дополнен (или сокращен) в соответствии с ситуацией на конкретном предприятии. В зависимости от того, является ли предприятие производственным, сервисным или торговым, отдельные виды деятельности могут быть рудиментарными или вообще отсутствовать; могут быть также добавлены виды деятельности, специфичные для данного предприятия. При необходимости виды деятельности могут быть детализированы (например, вид деятельности “Производство деталей и узлов” может быть дополнительно разбит на “Литье”, “Ковка, штамповка”, “Механическая обработка”, “Гальваническая и химическая обработка”, “Термическая обработка” и т.д.), хотя излишняя детализация может скорее помешать, чем помочь.

Для сервисных предприятий к категории “Производство” должны относиться те виды деятельности, которые формируют добавленную стоимость. У торговых или финансовых предприятий категория “Производство” может отсутствовать полностью.

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

Прежде всего необходимо заполнить колонку «Текущее состояние». В каждой из ячеек колонки должны быть перечислены все информационные системы, которые используются при осуществлении соответствующего вида деятельности. Если какая-то информационная система используется в нескольких видах деятельности, она должна упоминаться во всех этих видах. Не рекомендуется указывать инфраструктурные и общесистемные элементы (“локальная вычислительная сеть”, “СУБД Oracle”, “Операционная система Linux”, “Электронная почта” и т.п.), а также офисные программы общего назначения. Исключение – Excel, если при осуществлении какого-либо вида деятельности этот табличный процессор используется вместо полноценной информационной системы (часто в этих случаях применяется специальное приложение на базе Excel).

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

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

Таблица 1. МАТРИЦА ПОДДЕРЖКИ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ
ИНФОРМАЦИОННЫМИ СИСТЕМАМИ