Пирамида бизнеса в архитектуре предприятия

Принципы, модели и стандарты в рамках архитектуры предприятия

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

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

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

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

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

• Миссия и видение.
• Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий.
• Цели, задачи и стратегии.
• Архитектура информационных технологий.
• Политики (правила). Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов.
• ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. В случае, когда речь идет о стандартах, выбираемых государством, особенно важным является подход, когда стандарты описывают только наиболее общие и важные элементы технологий в соответствии с принципами честной конкуренции.
• Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.
• Руководства или рекомендации (guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

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

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

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

Важным представляется следующее замечание, сформулированное в архитектурной методике META Group, которое касается роли принципов и моделей в описании архитектуры (более подробно об этом см. в
«Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF»
). Можно сказать, что существуют два различных подхода к процессам разработки, описания и использования архитектуры предприятия: существенная, возможно, даже большая часть специалистов и компаний считает, что основой архитектуры являются принципы, а другая часть придерживается точки зрения, что основой архитектуры является процесс создания моделей. META Group полагает, что при описании сегодняшней, существующей архитектуры (архитектуры «как есть») необходимо в большей степени руководствоваться декларациями принципов, на основе которой она построена; в то же время, будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры.

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

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

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

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

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

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

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

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

Метамодель бизнес-архитектуры

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

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

Комплексное понимание стратегии и устройства компании

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

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

Согласованность людей, процессов, ресурсов, технологий, возможностей и стратегии

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

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

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

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

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

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

Создание системы показателей эффективности – непростая задача. Как раз в силу сложности взаимосвязей сущностей, с которыми связаны показатели.

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

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

Система показателей эффективности, как и бизнес-архитектура – инструмент управления. 

Формирование ценности в соответствии с потребностями заинтересованных сторон

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

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

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

Согласованность потребностей бизнеса и возможностей ИТ

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

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

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

Вывод процесса планирования на новый качественный уровень

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

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

С точки зрения планирования бизнес-архитектура позволяет избежать:

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

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

Приоритезация и обеспечение финансирования инициатив

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

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

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

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

Увеличение вовлеченности персонала и эффективности взаимодействия

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

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

Правильная бизнес-архитектура позволяет обеспечить вовлеченность двумя способами:

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

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

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

Время на прочтение
6 мин

Количество просмотров 2.8K

Бизнес-архитектура и ее место в компании

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

Таким образом, архитектура в городе — это наука не только о строительстве и проектировании, но еще и о структурировании.

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

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

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

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

Взгляд со стороны ИТ

Зачем вообще разрабатывать единую архитектуру для работы компании? Рассмотрим этот вопрос с точки зрения Блока информационных технологий Страхового Дома ВСК.

• Во‑первых, часто бывают случаи, когда Заказчик и Исполнитель смотрят по‑разному на одну и ту же автоматизацию. Поэтому единый взгляд очень важен, как и единое мерило (которое имеет однозначное трактование «да» или «нет).

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

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

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

Основные бизнес-составляющие

Так случилось, что в один момент ИТ‑архитектура нашей компании устарела и перестала отвечать на вызовы рынка. Развитие ее стало долгим, дорогим и мучительным. Появилась явная цель — избавиться от старых приложений (legacy out) и реализовать новые.

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

Сервисы

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

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

В методологии Agile, во фреймворке SAFe, есть понятие «Value stream». Это картирование — сбор и анализ информации о процессах в потоке, оптимизация операций с точки зрения ценности действий и целесообразности затрат. Ценность рассматривается с точки зрения клиента.

Можно сказать, что наши сервисы — это маленькие велью стримы. Они нарезаны вокруг услуги, продукта, канала продаж и взаимодействий.

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

Способности

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

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

Дашборды

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

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

Архитектура решения

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

Фронт работ над ПО: развитие функционала по первичному учет сервисов, интеграция с Jira, автоматическое обновление дашбордов, формирование требований и разработка функционала по работе со способностями.

Касательно сервисов, важно отметить следующие пункты:

• по каждому сервису необходимо определить реального владельца, отвечающего за его развитие;

• для каждой задачи в Jira необходимо указать сервис и/или способность;

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

  

Перспективы развития

В 2022 году мы определили целевую концепцию и разработали базовый функционал по сервисам. Далее рассматриваем следующий план взаимодействия с Бизнесом:

• ИТ дорабатывает инструмент, осуществляет первичное наполнение данными и использует дашборды для общения с Бизнесом об уровне и качестве автоматизации;

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

Стратегия развития бизнес‑архитектуры следующая:

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

• автоматизация сбора информации: автоматизация сбора данных об уровне и качестве автоматизации на основании сервисов, сбор статистики по сервисам → автоматизация ручного ввода;

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

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

Заключение

Выше описан взгляд Страхового Дома ВСК на организацию бизнес‑архитектуры и практический подход к реализации.

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

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

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

Если у Вас есть интерес — пишите skirillov@vsk.ru

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

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

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

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

• Классическая или, другими словами,
  эталонная архитектура предприятия
  является идеальной моделью построения
  организации.

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

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

Построение бизнес — архитектуры начинается
с описания контекста бизнес — архитектуры
(рисунок 1.8.).

Общее видение бизнес — архитектуры
предприятия включает анализ основных
функций, цепочек создания добавленной
стоимости (ValueLandscapeAnalysis), модели бизнес –
сценариев (BusinessScenarioModels), анализ информационных
связей и процессов (InformationValueChainAnalysis).

Рисунок 1.8.
Контекст бизнес архитектуры

Основу архитектуры предприятия
составляет: анализ бизнес событий
(BusinessEventAnalysis), декомпозиция функций
и процессов (Function/ProcessDecomposition), модель расположения
(LocationModel),
модель интеграции (IntegrationModel).

Бизнес — архитектура представляется в
виде набора бизнес моделей. Бизнес
модели – это «набор событий, связанных
с бизнесом, в который вовлечены различные
функции бизнеса, организационные единицы
и активы предприятия».

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

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

• Динамические модели бизнес-процессов,
  включающие детализированное описание
  функционирования компании.

• Организационная структура компании.

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

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

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

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

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

• выделить ключевые бизнес-процессы;

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

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

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

Модель интеграцииопределяет связь
бизнес-процессов и бизнес — событий.

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

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

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

4. ИТ — архитектура
предприятия

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

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

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

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

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

• Enterprise Information Architecture (EIA) –
  информационная архитектура.

• Enterprise Solution Architecture (ESA) –
  архитектура прикладных
  решений.

• Enterprise Technical Architecture (ETA) –
  техническая архитектура.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

Возраст: 45 лет

Образование: Московский институт стали и сплавов, Финансовая академия при Правительстве РФ

Послужной список последних лет:

Для каких предприятий и в каких случаях бизнес-архитектура и ИТ-архитектура имеют значение? Каким предприятиям реально требуются специалисты, которые ею управляют?

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

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

Что может стимулировать предприятие серьезно заняться своей архитектурой?

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

В ОМК сложился более благополучный сценарий: разработка архитектуры стала логичным шагом в поступательном развитии компании, стержнем которого является управление цепочками поставок. К счастью, в нашей компании собралась очень сильная команда специалистов в этой области. С созданием архитектуры вся конструкция системы управления обрела полноту. На верхнем уровне архитектуры — модель целей, главные из них — качество в широком смысле этого слова (включая своевременность поставок, точность оформления документов — все, что связано с удовлетворением потребностей наших клиентов) и скорость — необходимость удовлетворять спрос как можно быстрее (для этого нам приходится находить баланс между уровнем запасов и уровнем спроса). Эти цели определяют всю деятельность компании, включая закупки, перевозки, производство, хранение, продажи, для этого выстроены процессы, которые ведут к их достижению. В их основу положена модель SCOR (The Supply Chain Operations Reference Model), мы взяли этот стандарт, поскольку он впитал в себя лучший мировой опыт в области логистики. Для нас важно, что эта хорошо развитая модель продолжает интенсивно развиваться и совершенствоваться.

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

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

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

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

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

Каким образом выстроено управление бизнес-архитектурой и ИТ-архитектурой в ОМК? Есть ли в компании свое «архитектурное бюро»? Каковы здесь сферы ответственности, задачи, функции?

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

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

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

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

Каков уровень влиятельности бизнес-архитекторов и ИТ-архитекторов вашего предприятия? На какие решения они влияют? В каких этапах их рассмотрения и принятия они участвуют?

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

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

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

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

Как соотнести целевую бизнес-архитектуру и целевую бизнес-модель компании? Другими словами, как связать архитектуру и то, каким образом компания будет зарабатывать деньги?

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

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

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

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

Какие факторы могут стать причиной серьезных архитектурных трансформаций?

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

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

Технологические инновации могут быть действенным стимулом для архитектурных трансформаций?

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

Как часто следует подвергать ревизии целевую бизнес-архитектуру и ИТ-архитектуру?

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

По каким признакам можно определить момент, когда бизнес-архитектуре или ИТ-архитектуре компании необходима серьезная трансформация?

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

Какие схемы, способы, подходы к архитектурной транс­формации вы считаете наиболее эффективными?

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

Какие структуры предприятия обычно охватывает архитектурная трансформация бизнеса? Какие должностные лица оказываются ею обычно охвачены?

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

Кто должен выступить лидером архитектурной транс­формации?

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

Каково соотношение различных составляющих в транс­формации бизнес-архитектуры и ИТ-архитектуры?

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

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

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

Каковы наиболее сложные вопросы, связанные с управлением изменениями в архитектуре предприятия?

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

Еще одна проблема помельче — отсутствие инструментов для проектирования организационных изменений.

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

Какие уроки вы извлекли из своего опыта построения архитектуры?

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