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

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

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

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

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

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

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

Анализ компонент — это один из видов анализа, разработанный BCG (Boston Consulting Group), предполагающий грубую оценку принципов развития каждого бизнес-компонента компонентной модели.

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

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

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

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

Возможные варианты развития функций компонента показаны на рисунке ниже.

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

Если компонент основной, но не уникальный, рекомендуется применять стандартные, проверенные практики.

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

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

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

В результате анализа компонент был получен следующий результат:

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

Ещё один вид анализа компонентной модели — оценка бизнес-значимости. Для проведения такой оценки необходимо сформулировать цели развития компании (можно провести интервью с высшим руководством).

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

1. Принимать своевременные управленческие решения
   
2. Эффективно управлять проектами и процессами
   
3. Укреплять бренд и доверие на рынке

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

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

Для нашей строительной компании были получены следующие результаты оценки бизнес-значимости компонент:

Как оценить бизнес-значимость? Необходимо идти последовательно по каждому компоненту и задавать вопрос: «В какой степени деятельность компонента способствует достижению цели № 1/2/3…».

Например, компонент «Управление проектами» в явном виде способствует достижению цели № 1 — «Принятие своевременных стратегических решений», так как компонент агрегирует всю возможную актуальную информацию о текущих делах компании. Также очевидно, что компонент «Управление проектами» в явном виде способствует достижению цели № 2 — «Эффективное управление проектами и процессами». А вот достижению цели № 3 — «Усиление бренда компании и доверия на рынке» компонент способствует опосредованно. Непосредственно управление проектами не развивает бренд компании, но позволяет эффективно осуществлять основную деятельность компании, что повышает доверие к компании на рынке.

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

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

• Полнота информации (информации недостаточно)
  
• Целостность информации (информация противоречива)
  
• Доступность информации (информация неактуальна)
  
  

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

Для нашей строительной компании была получена такая оценка ИТ-проблематики:

В результате анализа ИТ-проблематики было выявлено, что «Управления проектами», «Контроль проектирования» и другие важные компоненты имеют высокую степень проблематики и испытывают проблемы за счёт недостаточного уровня ИТ.

Данный вид анализа демонстрирует возможность эффективного применения средств ИТ для компонента. Этот вопрос может быть разложен на несколько факторов.

1. Фактор необходимости. С точки зрения необходимости наиболее эффективным является внедрение средств ИТ в компоненты, которые по своей природе являются информационно насыщенными: данные предоставляются интенсивно, в большом объёме и являются критичными для деятельности компании.
   
2. Фактор возможности. Здесь необходимо определить, принято ли автоматизировать данный вид деятельности, есть ли на рынке такие решения, насколько быстро можно найти партнера и так далее.
   
3. Фактор готовности. Про этот фактор часто забывают, но он является очень важным. Фактор говорит об организационной готовности компании к применению средств автоматизации и цифровизации в рамках данного компонента. Бывает, что компонент информационно емкий и готовые решения на рынке есть, но по некоторым причинам (политическим, экономическим и другим) подразделения, осуществляющие работу данного компонента, не готовы к внедрению средств автоматизации.
   

Очевидно, что если все три фактора имеют высокую оценку, то и потенциал автоматизации компонента является высоким.

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

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

Так, для строительной компании можно сформировать следующие приоритеты автоматизации компонент:

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

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

Как сформировать модель данных предприятия? Необходимо последовательно идти по компонентам и фиксировать виды информации, которые:

1. Нужны для работы компонента
   
2. Создаются в компоненте
   
3. Приходят из других компонент
   
   

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

Например, информационные связи для области «Продажа» нашей строительной компании это будет выглядеть так:

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

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

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

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

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

Если предприятие небольшое (используется 5-7 ключевых систем), можно сразу соотносить данные с системами. Если же масштаб бизнеса большой, то полезно к конкретным системам прийти через классы систем. Классы систем — это виды прикладной функциональности (ERP, CRM, TMS и т.д.). Здесь мы говорим о том, какие возможности для работы с данными должна предоставлять та или иная система.

Так, в нашем примере со строительной компанией получилась такая модель целевого состояния классов систем:

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

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

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

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

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

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

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

Так, в нашем примере со строительной компанией получилось следующее:

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

Из практики можно сказать, что данные, которые мы считаем самыми важными, которые фиксируются в учётных системах и попадают в отчёты, составляют лишь около 20% от всех видов данных, необходимых для работы компонентов. Остальные 80% представляют собой неструктурированные данные. Таких данных становится больше с каждым годом, они напрямую влияют на принятие решений и их необходимо учитывать.


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

Например, для нашей строительной компании это может выглядеть так:

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

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

Можно сформулировать следующий укрупнённый алгоритм проектирования корпоративной архитектуры.

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

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

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