В моей статье рассматривается логика построения оргструктур в сложноорганизованных компаниях (холдингах) во взаимосвязи с логикой построения архитектуры бизнес-функций.
Для кого
Данная статья написана для бизнес-аналитиков, процессных-аналитиков, процессных архитекторов, которые в силу специфики своей деятельности (бизнес-процессы) не акцентируют большое внимание на данных типах моделей. Возможно некоторые аспекты будут интересны бизнес-архитекторам, не сталкивавшимся в своей деятельности с рассматриваемыми кейсами
Термины
В статье используются термины, которые по умолчанию возможно непривычны читающим.
- Актор –любой вид субъекта (юрлицо, подразделение, должность).
- Юнит – вид актора. для простоты для данной статьи определим, как юрлицо, т.к. в российской практике, в большинстве случаев это так.
- Метамодель – это вид модели, которая задает правила моделирования, но не является конечной моделью, отражающей реальную систему, т.е. модель про то «Как создавать модели?»
О чем в статье?
Коротко о видах архитектур акторов в Компании, просто чтобы понять, что оргструктура это не единственная модель такого рода.
Подробнее об организационной структуре. Казалось бы, простая и всем привычная иерархическая модель, но именно в силу привычности содержащая в себе некоторые логические «ловушки», не понимая которые, есть риск построить организационную структуру неправильно.
Бизнес-функция – важный элемент архитектуры и системы управления компанией, который точно должен быть выделен и управляем если наша компания имеет сложную логику управления. (Холдинги, матричные модели).
Итоговая взаимосвязь описанных видов архитектур с точки зрения влияния друг на друга.
1. Архитектуры акторов в корпоративной модели? Что может быть кроме оргструктуры?
На Рис.1 показана метамодель архитектуры владения активами Холдинга.
Как видно из метамодели она не про управление сотрудниками, а про управление активами, но при этом данный тип управления в каком-то смысле не менее важен, от него, например, выстраивается финансовая логика управления прибылью и связанные с этим бизнес-процессы. Далее будет показано использование элементов данной архитектуры при построении общей оргструктуры холдинга.
2. Подробнее об оргструктуре
На Рис.2 показана метамодель оргструктуры Компании.
Привычная нам иерархическая модель организационной структуры оказалась несколько сложнее с точки зрения смыслов, заложенных в нее.
Во-первых, очевидно прослеживается 2 независимых логики модели (Голубые и желтые элементы)
- Логика агрегации элементов (Вхождение сотрудников в подразделения и вхождения подразделений в вышестоящие подразделения.) Причем в основе - это функциональная агрегация, т.е. агрегация сотрудников по принципу общности выполняемых функций (профессиональной области). Иногда эта логика нарушается, чуть позже рассмотрим к чему это приводит.
- Логика управления (связи Руководитель/Подчиненный), 2 вида разнонаправленных связей., снизу-вверх руководитель получает от подчиненного необходимые ему функции, сверху вниз руководитель управляет административно.
Почему важно видеть картину именно в таком контексте и какие из этого можно сделать выводы.
Для целей управления сотрудниками, подразделения, как элемент оргструктуры, не нужны. Действительно на практике очень часто встречал ситуацию, когда подразделения в официальной оргструктуре отсутствуют, причем часто это бывает на самом верхнем и на самом нижнем уровне иерархии.
Подразделение нужно для того, чтобы агрегировать элементы, входящие в него (связь агрегация). С точки зрения смысла агрегация - это либо сумма множеств, либо просто сумма, если речь об арифметической логике. Соответственно основными параметрами подразделения и смыслом агрегации элементов могут быть арифметические суммы, например:
- «Количество сотрудников/Штатная численность подразделения»,
- «Сумма ЗП сотрудников подразделения»,
- «Сумма затрат на подразделение, с учетом аллокации общих затрат» либо множество «Набор функций как основа положения о подразделении», выполняемых сотрудниками подразделения.
Т.е. подразделение нужно включать в модель оргструктуры тогда, когда нам требуется логика агрегации элементов для целей управления, в противном случает этим элементом можно пренебречь.
Если провести короткий анализ связей между руководителем и подчиненным, то сверху вниз административное подчинение/управление, связь как минимум содержит в себе возможность руководителя ставить задачи/и или планы подчинённому и контролировать выполнение этих задач и/или планов, а снизу-вверх связь «Выполняю функции для» говорит о том, что, строго говоря существует контракт (должностная инструкция), ограничивающий требования руководителя к сотруднику теми функциями, который он выполняет. В более привычной нам картине (Organizational Chart / Orgchart) связь административного подчинения одна, она двунаправленная и содержит в себе обе описанные выше логики.
Какие проблемы могут быть, если строить оргструктуру без учета логики всех этих видов связей?
Приведу пример реализации модели оргструктуры в одном небезызвестном профильном программном продукте, автоматизирующем работу с персоналом. На уровне реализации разработчики не заложили возможности показать отдельные связи управления, т.е. назначить сотрудникам руководителя. Роль руководителя присваивается сотруднику, входящему в подразделение наряду с рядовыми сотрудниками, т.е. связи управления в данной реализации, во-первых, только вычисляемые, а во-вторых, их невозможно вычислить если нет подразделения. В результате управленческая оргструктура компании, утвержденная внутренним приказом будет содержать расхождения с данными справочника информационной системы, поскольку придется создавать «виртуальные» подразделения для того, чтобы построить правильную модель управления. Разработчики ПО явно не учитывали все нюансы такой модели как оргструктура. Как минимум это приведет к тому, что официальную оргструктуру из информационной системы мы сформировать не сможем, либо нам придется подгонять управленческую логику под возможности ИС.
Другой пример из практики проектирования оргструктур (рис.3).
В рамках построения системы продаж было принято решение об организации торговых представительств на территории присутствия, данные торговые представительства были занесены в иерархическую модель оргструктуры как подразделения и в них привязаны сотрудники/должности. В чем здесь проблема? Дело в том, что представительство в данном случае было просто местом размещения сотрудников, т.е. по сути элементом модели «Места расположения/элемент Location(Archimate)», а с точки зрения управления и агрегации данные сотрудники должны были входить в иерархию соответствующих департаментов продаж, причем по факту в одном представительстве находились сотрудники, работающие в разных департаментах.
Такой подход к построению оргструктуры привел к тому, что в итоге мы не смогли правильно агрегировать на уровне иерархии ни количества, ни суммы на соответствующих департаментах, т.к. сотрудники представительств формировали независимую отдельную ветку иерархии в оргструктуре, не имеющую к логике управления никакого отношения. Для формирования управленческой отёчности каждый раз приходилось часть данных корректировать вручную. Логика административного подчинения при этом естественно также на выстроилась, т.к. управляемые сотрудники находились в другой ветке иерархии, корректные связи административного подчинения отсутствовали.
Логика агрегации элементов оргструктуры в подразделения должна соответствовать функциональной логике управления, агрегировать нужно сотрудников как функции (функциональный критерий агрегации), а не место их расположения, это другой тип модели и в рамках оргструктуры он может быть только дополнительным признаком должности(сотрудника), а не элементом иерархии.
Таким образом, простая, на первый взгляд, иерархическая модель оргструктуры (Organizational Chart / Orgchart), содержит в себе несколько неочевидных логик, не учитывая которые можно допустить ошибки проектирования и в результате получить модель, которая не выполняет свои функции для принятия управленческих решений
3. Архитектура бизнес-функций.
Рис.4 Метамодель архитектуры бизнес-функций.
Зачем нужна архитектура бизнес-функций и как ее можно использовать?
Для начала вспомним что это такое –BPM CBOK говорит о бизнес-функции как о группировке деятельности по критерию области знаний (профессиональной области). Основной вопрос «Зачем нам нужна эта группировка?», мы на него в рамках статьи отвечать не будем, тема достойна отдельной статьи.
Для целей статьи в данном определении можно сделать акцент не на группировке деятельности, а на критерии группировки «Область знаний/Профессиональная область», что подразумевает под собой набор специфических знаний о данной области.
Очевидно, что в сложных компаниях одна и та же область деятельности повторяется в разных юнитах, т.е., например, стоит задача управления бухгалтерским учетом или финансами в нескольких десятках юридических лиц. Как управлять в данной ситуации?
На самом деле есть несколько вариантов, можно полностью централизовать деятельность (построить ОЦО) «Централизация деятельности», можно полностью унифицировать бизнес-процессы «Унификация деятельности», но в некоторых случаях в силу объективных причин или ограничений контекста ни тот ни другой вариант унификации с целью управления невозможен и тогда применяется унификация функционального типа, через управление правилами (требованиями, принципами, ограничениями).
Появляется роль «Владелец бизнес-функции» которая на уровне всего холдинга формирует набор правил/требований для бизнес-функции.
Рис.5 Метамодель содержания бизнес-функции.
Данный набор правил (Принципы, Требования, Ограничения, Понятия) можно назвать Методологией бизнес-функции. С управленческой точки зрения Роль владельца Бизнес-функции состоит как минимум в разработке данной Методологии, а также в доведении ее до сотрудников, отвечающих за выполнение Методологии на уровне юнита и в последующем контроле соблюдения данной методологии, что является основной управленческой связи с привычным названием «Функциональное подчинение».
Почему важно осмысленно проектировать и разделять разные виды управления (административное/функциональное), потому что это оказывает прямое влияние на эффективность управления. Данные виды управления с одной стороны не должны перекрывать/дублировать друг друга, т.к. это вызывает у управляемого сотрудника непонимание и недовольство, а с другой стороны не оставлять пробелов в управлении, поэтому важно наполнять данные типы связей конкретным/точным смыслом, а не просто называть их разными словами (Административное/Функциональное).
4. Итоговая метамодель.
На Рис.5 приведена суммирующая метамодель (Оргструктура холдинга/Бизнес-функции)
В данной метамодели показана логика построения единой кросс-юнитовой оргструктуры холдинга, а также логика функционального управления со стороны УК бизнес-функцией (Розовая и Оранжевая связи).
Помимо уже описанных в статье рассуждений можно сделать еще одно наблюдение на основе данной метамодели. Дополнительная связь «Функциональное подчинение» возникает тогда, когда в нашей строгой одномерной иерархии нарушается принцип функциональной агрегации элементов в элементе «подразделение». В данном случает речь идет о верхнем уровне где группа формируется по юнит/логике, где подразделение это - юридическое лицо, содержащее в себе логику нескольких бизнес-функций.
Какие Выводы можно сделать на основе материала статьи?
Помимо оргструктуры, существуют еще некоторые архитектуры/модели акторов, которые можно(нужно) создавать для отражения разных аспектов внутреннего устройства сложных компаний.
Привычная нам оргструктура, на самом деле несколько сложнее, чем мы привыкли представлять ее в силу отсутствия акцента на этом виде модели и «замыленности»/привычности представления в стандартной нотации (Organizational Chart / Orgchart).
Правильное проектирование организационной структуры, позволяет осмысленно применять модель для целей последующего управления и делать это управление более эффективным.
Архитектура бизнес-функций и ее связь с оргструктурой – обязательный элемент бизнес-архитектуры сложных компаний, позволяющий обеспечить минимальный уровень функциональной управляемости (Методология бизнес-функции) сквозным образом для набора управляемых юнитов компании.
Алексей Телегин,
Бизнес-архитектор. Проектирование бизнес-архитектур в промышленных холдингах более 5 лет. IT директор. Развитие IT в промышленных холдингах и банках более 20 лет.
Декабрь 2025 г.