В моей статье рассматривается проблематика построения корпоративной модели в крупных компаниях. Часто даже при наличии в компании практики работы с бизнес-процессами в рамках архитектуры процессов нет возможности отразить все аспекты сложной корпоративной модели, либо процессная модель неудобна как средство визуализации конечным потребителям от бизнеса, руководителям или даже собственникам компании. Также существует влияние других элементов корпоративной модели на архитектуру процессов, без учета такого влияния качество самой архитектуры процессов будет ниже.
Для кого.
Данная статья написана для бизнес-аналитиков, процессных-аналитиков и процессных архитекторов, осуществляющих свою деятельность в крупных, сложно устроенных, компаниях и имеющих цель повысить свою квалификацию с точки зрения способности моделирования и анализа элементов корпоративной модели, находящихся вне рамок архитектуры процессов.
Что будет и чего не будет в статье?
Корпоративная модель - многомерная логическая структура, которая помимо привычных нам бизнес-процессов включает в себя множество элементов, описывающих компанию во всех ее аспектах, как с точки зрения операционной деятельности, например помимо процессов это элементы ИТ (информационные системы и т.п.), физические элементы (станки в цехе, здания, инструменты), так и с точки зрения внутреннего и внешнего контекста(заинтересованные стороны, продукты, потребительская ценность), ну и наконец модели развития (стратегии, цели и результаты/показатели, направления развития и стратегические инициативы). Но для упрощения задачи в данной статье мы будем касаться только элементов операционной деятельности и немного внешнего контекста/рынка. Ну и конечно не будет примеров из ИТ и технологического слоев. Речь пойдет только о бизнес-архитектуре.
Что есть в Бизнес-архитектуре Компании кроме процессов?
На Рис.1 отображены некоторые элементы/классы бизнес-архитектуры, которые в том или ином виде присутствуют в главной «Библии» специалистов по процессному управлению BPM CBOK.
Проблемы их осмысленного применения с точки зрения практики Process Management я вижу две.
Проблема 1. В BPM CBOK некоторые из этих элементов описаны и даже даны определения, а некоторые упомянуты вскользь, но все они рассмотрены с точки зрения процессо-центричности данного свода знаний, к этому нет никаких претензий т.к. свод знаний то Process Management. Но по этой причине довольно трудно понять из описания, что конкретно имеется ввиду и самое главное, как это применять.
Проблема 2. Когда мы говорим о бизнес-архитектуре мы имеем ввиду прежде всего визуальную модель, сформированную обычно в некоторой графической нотации. Перечисленные в BPM CBOK нотации формирования модели касаются только процессов и не затрагивают никакие другие элементы бизнес-архитектуры.
Рис.1 Элементы бизнес-архитектуры
Таким образом, BPM CBOK явно не охватывает все значимые аспекты модели Компании и не позволяет создать полную Корпоративную модель и даже Бизнес-архитектуру. Нужно что-то больше как в части методологии, так и в части инструментов визуализации.
Немного о пользе архитектуры.
Принцип пользы – это один из основных архитектурных принципов, т.е. любой элемент корпоративной архитектуры должен иметь сценарий использования каким-то бизнес-потребителем.
Но этот принцип работает в обе стороны, т.е. если говорить о полной модели бизнеса, то помимо процессов и пользы от их моделирования/анализа/проектирования существует еще множество важных элементов, имеющих место в бизнесе и, следовательно, несущих пользу от их моделирования и последующего использование в виде моделей.
Методология.
Очевидно необходим какой-то другой набор методологий кроме BPM CBOK для создания той части бизнес-архитектуры, которая находится вне процессов. Таким набором, может стать сочетание архитектурного фрэймворка TOGAF, как методологии и языка Archimate как средства визуального моделирования.
Почему именно данное сочетание (TOGAF+Archimate)?
На самом деле альтернативы есть: FOAF, Zachman Framework, MODAF, DoDAF, FEA, Gartner Enterprise Architecture Framework.
Конечно есть основа всех архитектурных и не только методологий с точки зрения теории построения/управления системами – это системная инженерия, но эти глубины мы затрагивать не будем, ввиду прикладного характера статьи.
С «дедушкой» (Zachman)ом все понятно, это прародитель и основа всей современной архитектурной теории и практики управления архитектурами бизнеса, нужно знать и использовать, т.е. это не альтернатива, а основа/база. А вот остальные альтернативы не имеют настолько широкого распространения в силу разных причин, а прежде всего в силу того, что указанная связка (TOGAF + Archimate) принадлежит одной международной организации https://www.opengroup.org/, развивается синхронно и увязана между собой с точки зрения логики применения. Кроме того, каждый из элементов связки находится на высоком уровне зрелости. Т.е. эта связка содержит в себе все необходимые методологические и, что немаловажно, визуальные основы для управления архитектурой компании.
Примеры применения. Что есть в бизнес-архитектуре кроме бизнес-процессов?
Кейс 1. «Клиентоориентированный Продуктовый каталог»
Часто встречается ситуация, когда иерархия продуктового каталога компании строится только по производственной/конструкторской (физической) логике. Не утверждаю, что такая логика неверна, вопрос сценариев применения. Для производственных и технологических процессов/целей верна абсолютно. Но есть ведь наши любимые клиенты. А для клиентов наша внутренняя логика в большинстве случаев абсолютно не интересна.
Как быть?
Перегруппировывать позиции нижнего уровня («Артикулы») по клиентской/рыночной логике. На Рис.№2 (Метамодели №1) показана возможная зависимость модели продуктового каталога компании от рынка. Логика построения иерархии продуктового каталога задается иерархией потребительских ценностей и сегментов рынка. Существует очевидный сценарий использования продуктового каталога, сформированного по такой логике – внешние интерфейсы продуктов компании доступные клиенту с целью приобретения (сайты, компании, интернет магазины и т.п.). Основные потребители подразделения маркетинга, продаж, ИТ в части разработки продуктовых интерфейсов.
Мало-того, в зависимости от методов сегментации рынка, таких группировок/иерархий может быть построено несколько. И каждая может быть использована для своих целей.
При этом на уровне архитектурной практики и системы можно остаться в логике метамодели, т.е. не выстраивать реальные продуктовые каталоги в архитектурной системе (например, в Business Studio), а просто сформировать, согласовать и отдать правила в виде метамодели в описанные выше подразделения для того, чтобы дальше они могли этим руководствоваться в своей работе.
Как мы видим в данном случае процессы вообще никак не затрагивают эту логику. Модель процессов в этом случае бесполезна.
Рис.№ 2. Метамодель №1. Продукты, потребительская ценность, маркетинг.
Кейс 2. «Метамодель расположения бизнеса»
В архитектуре процессов никак визуально не отражена логика мест расположений нашего бизнеса, а ведь бизнес-модель Компании может предполагать, что этот элемент «Места расположения» как минимум не менее, а может быть и более важен с точки зрения управления, чем процессы. Представим себе условный «McDonalds» - огромная корпорация, но процессная модель там сильно типизирована независимо от места присутствия, т.е. мы по сути один раз проработав архитектуру процессов начинаем расставлять ее по территориям/рынкам с целью масштабирования. Здесь конечно добавятся сами процессы масштабирования, но они тоже будут типовыми. А вот дальше нам просто необходима возможность управлять юнитами на территориях и логистикой, т.е. материальными потоками в рамках данной модели. Это про аспект «где» Zachman Framework.
На Рис.№3. Показана метамодель 2. Архитектура мест расположений. Это основа(база), для построения как логистических моделей Компании, так и моделей управления. Тут присутствует как чистая география, т.е. объективная картина устройства нашего мира Мир/Страна/Регион/Город/Адрес, так и территориально-управленческая логика Макрорегион/Маркетинговая территория. Данная метамодель задает правила структурирования экономической географии присутствия компании. И имеет как самостоятельную ценность, так и ценность с точки зрения использования ее в других моделях. Это именно метамодель (модель построения моделей), которая задает правила формирования модели, а сама иерархия территорий присутствия может быть создана уже как справочник/справочники в информационных системах, отвечающих за автоматизацию деятельности. Т.е. архитектурная практика может остановится на этом уровне и не создавать в архитектурной системе полную модель мест расположения.
Рис.№ 3. Метамодель №2. Места расположения.
Кейс 3. «Юнит-метамодель. Управление большой Корпорацией».
Проблема модели управления в большой компании, а особенно в Корпорации заключается в следующем.
Система управления есть в архитектуре процессов - это как минимум все процессы управления и их связи между собой и с управляемыми процессами на разных уровнях, и эту логику управления знает процессный архитектор – это его хлеб. Проблема в том, что кроме него эту логику в полном объеме не знает никто и нет никакой физической возможности донести весь объем этой логики до сознания Генерального директора. Т.е. из архитектуры процессов логику управления может вычислить Архитектор, но не может, а точнее не будет, вычислять Генеральный директор, за редким исключением Генерального директора ГИКа ☺, но это клиника, а не норма.
Нужно что-то сильно попроще.
На Рис. №4 представлена Метамодель 3, описывающая логику управления Компанией/Корпорацией в очень компактном виде.
Здесь есть основная бизнес-логика управления от Управляющей организации/юнита Корпорации, через управление направлением бизнеса (Бизнес-юнит), далее 2 уровня управления, отвечающие за присутствие на территории Юнит макрорегиона и Территориальный юнит, связанные с метамоделью мест расположений. И, наконец, внизу «боевые» юниты на «земле», отвечающие за производство и дистрибьюцию.
Чуть правее и внизу обеспечивающие сервисные юниты в виде ОЦО (Общий центр обслуживания), которые не включены в основную бизнес-логику и формируют отдельную логику управления.
И наконец справа выстроена дополнительная логика управления, показанная через связи специализации. Юрлицо, как логика управления активами/владением и ЦФУ, как логика оперативного управления финансами.
Рис.№ 4. Метамодель №3. Юнит-метамодель. Логика управления.
Таким образом, в рамках одной компактной метамодели можно показать CEO или собственнику основные аспекты управления Корпорацией любого размера и такой вариант заведомо лучше, чем пытаться донести это через архитектуру процессов управления(IDEF0).
Кейсы 4. «Поговорим о бизнес-способностях».
В BPM CBOK дано определения бизнес-способности из которого понятно, что это тот же бизнес-процесс, только на другом уровне абстракции. Из данного определения не совсем понятно, что же это все-таки такое и совсем непонятно, как и зачем это использовать)).
Поскольку процессные специалисты постоянно имеют дело с бизнес-процессами, то модели процессов для них становятся обыденностью и перестают восприниматься как абстракции, поэтому попытка представить себе бизнес-способность приводит к выводу что это абстрактное «нечто» в нашей работе не нужно и, следовательно, не имеет применения.
На самом деле в корпоративной модели почти любой элемент — это абстракция, по крайне мере моделирование экземпляров объектов не рекомендовано в силу необходимости соблюдения принципов твердости/жесткости архитектуры, экземплярами оперируют уже информационные системы отвечающие за автоматизацию деятельности (там где работаю сотрудники, а не архитекторы). Поэтому вопрос только в необходимости использования данной абстракции (Бизнес-способность) и пользе применения.
Архитектурное моделирование построено на понятии «Слой» (условное разделение уровней абстракций) и принципах отделения логики субъекта от его интерфейса (как субъект выглядит для внешнего потребителя) и действия от его внешнего проявления (сервиса).
В общем то, по отношению к процессу у бизнес-способности работает похожая логика. В каких-то случаях нам необходимо отделить процесс/группу процессов от его бизнес-результата (выхода важного с точки зрения компании). См. Рис.№ 5.
Рис.№ 5. Метамодель №4. Метамодель отношения бизнес-процесса и бизнес способности.
Итак, хватит теоретических рассуждений, давайте на примерах.
Новая бизнес-способность.
Представим ситуацию, когда нам как компании необходимо реализовать на рынке новую услугу. Наши действия в большинстве случаев будут предполагать поиск сотрудника с опытом предоставления данной услуги и далее попытку продать эту услугу.
Очевидно, что в данной ситуации никакого процесса нет, точнее процесс может быть и есть, но он нам абсолютно не важен во всех подробностях и уровнях детализации. Нам важна только способность продавать нашу услугу на рынке. Т.е. бизнес-способность у нас есть, как набор требований к результату/выходу, а процесса нет (черный ящик с сотрудником).
Сложная архитектура процессов.
Привычная нам архитектура процессов очень часто строится по логике бизнес-способностей, т.е. верхний уровень архитектуры разбит на группы именно по этому принципу и, в этом случае, скорее всего бизнес-способности как отдельные элементы нам будут не нужны т.к. их свойства (параметры бизнес-результата) можно просто сделать атрибутом/документом соответствующей группы процессов.
Но при построении верхних уровней архитектуры по другим принципам, например, несколько ЦСЦ разных бизнес-единиц или по принципу управления разными группами процессов единым руководителем, единая визуальная картина бизнес-способностей полностью теряется, в архитектуре соответствующие группы процессов «расползаются» по разным подуровням.
Кроме того, возможна ситуация, когда разные группы процессов на определенном уровне архитектуры, объективно отличающиеся по внутреннему содержанию, но реализуют одну и ту же бизнес-способность.
Рис.№ 5. Метамодель №4. Производство Toyota Land Cruiser 300 )))
На рис.5 ситуация подразумевает, что результаты работы 2-х заводов одинаковы, при этом процессы отличаются очень сильно. Необходим элемент, содержащий в себе параметры результата, но не содержащий подробности получения данного результата, т.е. бизнес-способность. Как вариант – хранить в элементе бизнес-способность конструкторскую документацию, а вот технологическая будет храниться уже в соответствующих процессах каждого завода (точнее каждого типа завода). Пример возможно условный и не совсем корректный, я слабо представляю себе внутреннее содержание процессов в компании Toyota, но как демонстрация подхода выделения отдельного элемента (бизнес-способность) вполне понятный.
Похожая картина в более привычных процессным профессионалам элементах демонстрируется на связке должность оргструктуры/роль. Роль не нужна, когда оргструктуры одномерна (небольшое предприятие), в этом случае дорожкой модели процесса BPMN будет должность. Но когда нам необходимо смоделировать единый процесс для 5 разных бухгалтерий, то без использования роли «Бухгалтер по заработной плате» уже никак не обойтись и тогда нет необходимости моделировать 5 процессов для 5 бухгалтерий только из-за того, что должностей тоже 5. Это вопрос эффективности процессной/ архитектурной практики и отсутствия/наличия рисков из-за необходимости поддерживать скопированную логику в 5 одинаковых по сути процессах.
Управление масштабированием бизнеса.
В больших, территориально-распределенных компаниях, когда бизнес представляет собой набор стандартных юнитов (и соответственно процессов) просто расставленных по территориям возникает необходимость независимой оценки и управления каждым таким юнитом или кустом юнитов (маркетинговой территорией). Процессы то одинаковые везде, как быть?
Можно применить метод из TOGAF (Capability based planning). И составить карту бизнес способностей (Рис.№7) для каждого юнита или куста юнитов (Рис.№6).
Рис.№ 6. Метамодель №5. Бизнес-способности операционных юнитов на территориях.
Рис.№ 7. Карта бизнес-способностей.
«Тепловая» карта бизнес-способностей позволяет провести универсальную оценку результативности/производительности любого юнита с точки зрения процессов, которые он выполняет и в дальнейшем использовать результаты оценки для принятия управленческих решений.
В данному случае, с точки зрения пользы, речь идет уже даже не о самом элементе бизнес-способность, а о дополнительном управленческом артефакте (Business capability map), сформированном для каждого юнита или группы управляемых юнитов на основе класса «Бизнес-способность».
Кейсы 5. «Бизнес-функция, еще один неведомый зверь».
Очень интересный и, на мой личный взгляд сильно не однозначный элемент Бизнес-архитектуры. Поэтому о нем поподробнее.
Из определения PBM CBOK становится понятно, что Бизнес-функция, во-первых, это тоже про деятельность, а во-вторых про деятельность, сгруппированную не по принципу бизнес-результата (бизнес-процесс/бизнес-способность), а по принципу единства профессиональной области (или области знаний), т.е. это про то что знают и умеют сотрудники, как основной ресурс компании.
В архитектурной практике (Archimate) определение бизнес-функции очень похоже, т.е. с точки зрения смысла определения очень похоже на BPM CBOK.
В чем подвох?
Как применять данный элемент, не очень понятно, особенно с учетом того, что в BPM CBOK данный элемент применяется как часть архитектуры процессов. Такой подход, на мой взгляд, сильно путает. Если бизнес-функция — это группа процессов, т.е. часть архитектуры процессов, то как быть с соответствием определению бизнес-функции. В большинстве современных компаний процесс кросс-функционален на самом нижнем уровне (поток работ /операционная модель), причем часто это участие 2, 3 и более бизнес-функций (с точки зрения области знаний) в операционной модели процесса. Т.е. определяя бизнес-функцию как деятельность сгруппированную на основе области деятельности(профессии) мы противоречим наличием внутри этой группы кросс-функциональных процессов. Тут в самом названии класса есть противоречие Бизнес-функция и кросс-функциональный поток работ как составляющая часть Бизнес-функции.
Похожая ситуация в архитектурной практике (Archimate). В определении сказано, что бизнес-функция - это действия, сгруппированные по области знаний/профессии, т.е. внутри себя как композита/агрегата бизнес-функция не может содержать такой тип элемента как процесс, который по определению имеет кросс-функциональную природу, т.е. содержит в себе элементы других бизнес-функций. Но при этом в самом стандарте (Спецификация Archimate) в примере бизнес-функция состоит из бизнес-процессов и взаимодействий. Что имели ввиду авторы? Если кросс-функциональные процессы, тогда такой пример противоречит определению, а если процессы имеющие строго функциональную природу, исполнители которых относятся к данной бизнес-функции, то строго говоря, такие вещи нужно пояснять.
Если добавить к этим рассуждениям логику нотации IDEF0 (а это методология Функционального моделирования), в которой сейчас в основном формируется архитектура процессов, то тоже нет однозначности, хотя бы потому, что существуют варианты группировок процессов (группа IDEF0), имеющих нефункциональную природу. Вот три примера, когда группа процессов IDEF0 имеет нефункциональную природу. Можно создать группу на основе цепочки создания ценностей (много функционально-ориентированных подгрупп внутри объединенных в цепочку), можно создать группу для юнита (тоже много функционально-ориентированных подгрупп относящихся к юниту) и наконец можно создать группу по критерию управления несколькими функционально-ориентированными группами процессов одним ТОП руководителем (внутри не одна, а несколько функционально-ориентированных никак не связанных друг с другом групп процессов кроме критерия/процесса управления). Во всех этих случаях группа процессов верхнего уровня не будет иметь функциональную природу, т.е. не являться «Бизнес-функцией» из практики BPM. Получается группа IDEF0 в архитектуре процессов в каких-то случаях «Бизнес-функция», а в каких-то нет. Т.е. Бизнес-функция, в архитектуре процессов - это возможное свойство группы процессов, а не самостоятельный класс.
В общем моя точка зрения, что даже когда группа процессов в архитектуре носит функциональный характер «Бухгалтерский учет», то это не Бизнес-функция по определению, а функционально-ориентированный процессный композит/агрегат.
Исходя из вышеописанных рассуждений, я осознанно не называю никакую часть архитектуры процессов «Бизнес-функцией», чтобы строго разделить классы элементов по смыслу применения. Можно считать это странностью с моей стороны, но она вызвана стремлением внести большую методологическую строгость на уровне понятий и классов элементов. В общем моя архитектура - мои правила ☺, каждый имеет право на свою точку зрения.
Где же найти в бизнес-архитектуре бизнес-функцию, если исключить методологически спорные, по моему частному мнению, варианты именования бизнес-функцией функционально-ориентированных процессных композитов в архитектуре процессов, чтобы избежать вышеописанных методологических терзаний.
В явном виде, в виде моделей, бизнес-функции я пока не применяю, с учетом того, что используемый инструмент (Business Studio) до недавнего времени не давал мне таких возможностей. И тем не менее при создании системы хранения некоторых элементов, совершенно четко прослеживается строго функциональный принцип группировки.
Во-первых, это знакомые всем бизнес-роли. В той части в которой бизнес роль служит агрегатом специфических для данной профессии операций в процессах. (Рис. №8).
Рис.№ 8. Метамодель №6. Связь бизнес-функции с операциями бизнес-процессов.
Папка навигатора системы Business Studio с ролями всех видов, например, бухгалтерских сотрудников как раз и будет тем аналогом бизнес-функции «Бухгалтерский учет и отчетность» о котором идет речь в BPM CBOK, т.к. представляет собой пусть не прямую, а опосредованную, через роли, агрегацию всех действий, выполняемых всеми видами бухгалтеров Компании независимо от сложности оргструктуры. Т.е. это как раз про группировку действий в рамках профессиональной области, а не про бизнес-результат (см. Определение бизнес-функции).
Во-вторых, и этот аспект моделирования намного более важен, строго через функциональный принцип выстраивается система хранения нормативно- справочных документов, определяющих методологию (методы, требования, шаблоны, принципы, ограничения), т.е. те правила, а в итоге знания и навыки которыми руководствуется сотрудник в своей ежедневной работе с точки зрения его профессии (области деятельности). Т.е. это общий свод знаний, который определяет каждую профессию в отдельности и группу профессий области знаний в единой системе хранения (логической папке «Бизнес-функция»). Рис. №9.
Рис. № 9. Метамодель №7. Бизнес-функция, как агрегат правил(требований) данной профессиональной области.
В системе Business Studio у нас пока это выглядит вот так.
Таким образом, можно использовать элемент/класс Бизнес-функция для формирования системы хранения элементов бизнес-архитектуры, имеющих строго функциональную природу, бизнес-роли и элементы аспекта «Мотивация» Archimate (принципы, требования, методы, шаблоны, определения), задающие правила работы Бизнес-функции.
Кейс применения Бизнес-функций для управления масштабированием бизнеса.
Кейс вымышленный, но теоретически возможный, связанный с оценкой зрелости бизнес-функций, в юнитах территориально-распределенных компаний. На рисунке №10 приведена обезличенная метамодель юнит-структуры крупного бизнеса в связке с метамоделью расположения и возможными бизнес-функциями которые выполняются в процессах данных юнитов.
Рис.№ 10. Метамодель №8. Связь бизнес-функций и юнитов на территориях присутствия.
По аналогии картами Business Capability Map можно создавать тепловые карты оценки бизнес-функций (Рис.№ 11.) для управления территориально распределенной структурой (юнитами) Компании.
Рис.№ 11. «Тепловая» карта бизнес-функций.
Оценка в данном случае будет проводится не процессов (результативность/эффективность), а уровня готовности наших ресурсов/сотрудников к выполнению их функций т.е. уровень готовности бизнес-функций. Соответственно и управленческие решения в данном случае будут в отношении HR (управление сотрудниками), а не процессами юнитов. В данном случае ценность применения опять имеет не сам класс «Бизнес-функция», а артефакт «Тепловая карта бизнес функций», формируемый для задач управления ресурсами юнита.
Кейс 6. «А что с архитектурой процессов?».
Ниже приведен обезличенный пример модели процессов Корпорации Рис.№ 12., привычная нам картина в нотации IDEF0.
Как видно на модели присутствует отражение в том или ином виде многих элементов вышеописанной в статье логики. У нас присутствуют группы процессов, синхронизированных с юнит моделью. Есть группа процессов управления управляющего юнита корпорации, есть 2 цепочки создания ценности, соответствующие 2-м бизнес-юнитам и 2 группы обеспечивающих процессов сервисных юнитов разного типа. Кроме того, выходы 2-х ЦСЦ связаны с продуктами и потребительскими ценностями формируемыми данными ЦСЦ.
Таким образом, процессная модель во многом зависит от других элементов бизнес-архитектуры и другие элементы оказывают влияние на архитектуру процессов.
Рис.№ 12. Метамодель №9. Отражение в архитектуре процессов других элементов.
Итак, какие Выводы можно сделать на основе материала статьи.
Бизнес-архитектура – это часть корпоративной архитектуры, которая помимо процессов содержит еще множество элементов, описывающих компанию в разных ее аспектах.
Некоторые аспекты компании, даже если они в каком-то виде присутствуют в архитектуре процессов проще моделировать через другие элементы бизнес-архитектуры, не забывая о пользе нашей работы (архитектурной практики) для Бизнеса.
Для больших и сложных компаний невозможно создать адекватную корпоративную модель/бизнес-архитектуру, не прибегая к достаточно широкому спектру элементов моделирования помимо бизнес-процессов.
Архитектура процессов сильно зависит от других элементов бизнес-архитектуры и ее качество во многом определяется качеством моделирования других элементов.
В рамках одной методологии BPM (BPM CBOK) невозможно построить адекватную и качественную бизнес-архитектуру. Необходимо знать и использовать специализированные архитектурные методологии и средства визуализации (как вариант TOGAF/ARCHIMATE). Знание специальных архитектурных методологий во многом определяет отличие роли процессного архитектора от бизнес-архитектора.
Современные средства моделирования (Business Studio версии 6 и выше) содержат в себе необходимый набор элементов для построения полной бизнес-архитектуры Компании и корпоративной архитектуры.
Метамоделирование – мощный инструмент формирования правил моделирования (альтернатива/основа соглашения о моделировании) и формирования компактных моделей, объясняющих устройство Компании для демонстрации ТОП руководителям и собственникам с целью формирование у них четкой картины управления и повышения качества принятия управленческих решений.
Алексей Телегин,
Бизнес-архитектор. Проектирование бизнес-архитектур в промышленных холдингах более 5 лет. IT директор. Развитие IT в промышленных холдингах и банках более 20 лет.
Февраль 2025 г.