Как моделировать оргструктуру при росте, M&A и трансформации бизнеса — без Visio, HRIS и тяжёлого консалтингового ПО

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

Оргструктура перестанет быть «картинкой для HR».

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

Особенно резко это проявляется после M&A: компания покупает активы, объединяет бизнес-юниты, стягивает производственные, коммерческие и административные функции, пытается создать единую управляющую компанию — и внезапно выясняется, что прежняя ручная модель больше не держит масштаб.

В этом нет ничего плохого. Это естественная стадия роста бизнеса.

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

И вот тут начинается боль.

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

Для зрелого бизнеса этого мало.

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

Неважно, говорим мы о коммерческих продуктах, производственных мощностях, административных сервисах, IT, HR, финансах, закупках, юристах или управляющей компании.

Вопрос не в том, как красиво нарисовать квадратики.

Вопрос в том, как собрать такую структуру, чтобы:

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

И инструмент либо помогает этот разговор вести, либо начинает мешать.

На одном из таких кейсов, совместно с коллегами из института Адизеса, я столкнулся с технической проблемой.

У них был старый практический инструментальный ориентир — OrgPlus.

Это была довольно архаичная, но в чём-то очень правильная программа: без кода, без конструкторов, без Visio/Figma/Miro-шаманства она позволяла быстро управлять структурными блоками, массово их таскать, редактировать и не думать о том, как вручную перерисовать дерево.

Дерево строилось само.

И это принципиально.

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

Но была и проблема: современного лёгкого аналога для такой работы я не нашёл.

Visio, Miro, Figma и PowerPoint хороши для рисования и презентаций, но это всё равно ручная работа с прямоугольниками и стрелками.

HRIS и ERP-системы хороши для эксплуатации утверждённой структуры, но это тяжёлый корпоративный контур, а не быстрый инструмент моделирования.

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

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

Так я начал делать свой ORGFORMAT.

Мне был нужен не «ещё один редактор оргсхем».

Мне был нужен инструмент для моделирования организационной трансформации.

То есть такой инструмент, где модель:

Так появился ORGFORMAT: открытый формат `.orgf` и бесплатный визуальный редактор ORGFORMAT Studio.

Суть простая: модель должна быть не картинкой, а переносимым файлом. Её можно открыть в Studio, показать на экране, обсудить, изменить, выгрузить в SVG/HTML/таблицу или отдать в AI как машиночитаемый код.

В оргтрансформации часто начинают с As Is: как компания устроена сейчас.

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

Дальше начинается To Be: будущая структура, которая должна лучше соответствовать стратегии бизнеса.

На практике это выглядит так:

И всё это нужно не просто нарисовать.

Каждую ветку надо защитить.

Почему эта функция здесь? Почему она подчиняется этому уровню? Почему бюджет сидит тут? Почему эта команда обслуживает несколько дивизионов? Почему эта роль остаётся на месте, а эта уходит в центр?

В обычной презентации такие вопросы быстро превращают схему в хаос.

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

В таких обсуждениях почти всегда возникает возражение:

«Но у нас же матричная структура».

Или:

«Эта функция обслуживает несколько подразделений».

Или:

«IT, HR, маркетинг, юристы и финансы работают на разные бизнес-юниты, значит, дерево не подходит».

Я с этим не согласен.

Не каждая кросс-связь должна становиться процессной связью на схеме.

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

Например, IT-служба может обслуживать несколько коммерческих дивизионов. HRBP может работать на площадке, но методологически жить в HR-функции. Финансовый контролёр может быть рядом с бизнесом, но стандарты и требования получать от финансового блока.

В ORGFORMAT это можно моделировать проще:

Это не отменяет процессов.

Это просто не заставляет превращать каждую управленческую неоднозначность в паутину стрелок.

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

Вторая типовая проблема стратсессий — участники слишком быстро начинают сопоставлять будущую структуру с ФИО и юридическими лицами.

Системно это часто ошибка.

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

Но полностью игнорировать людей и юрлица тоже нельзя.

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

Для этого в ORGFORMAT есть теги.

Тегами можно отмечать:

В итоге теги становятся простой наглядной базой данных поверх структуры.

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

Я не видел ни одной крупной организации на стадии роста, где одна функция всегда равнялась одному ФИО.

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

Если это видно уже на модели, разговор становится предметным.

Не «кажется, Иван Иванович перегружен», а «вот все функции, где Иван Иванович указан как потенциальный владелец, вот их value, вот их PAEI-логика, вот уровень риска».

Это уже другой разговор.

Теперь главное: ценность.

Оргструктура без числового слоя слишком легко превращается в политическую картинку.

Каждый блок может выглядеть одинаково, но за одним стоит 5 человек и локальная задача, а за другим — 400 сотрудников, производственный контур, закупки, склад, юристы, IT и половина EBITDA компании.

Поэтому в ORGFORMAT у каждого блока может быть value.

Что это такое — решает пользователь:

Главное, что value считается по всей ветке снизу вверх.

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

И да, для меня это, по сути, VAD — Value-Added View / Value-Added Design / Value-Added Chain в прикладном организационном смысле.

Можно спорить о терминах, нотациях и школах. Я как раз считаю этот спор полезным.

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

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

А если помогает — её уже можно обсуждать как модель.

Есть ещё один простой, но болезненный момент.

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

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

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

В модели это видно сразу.

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

На стратсессиях редко получается сразу собрать идеальную модель.

Времени не хватает. Данных не хватает. Руководители спорят. Собственник хочет посмотреть несколько сценариев. Финансы обещают потом прислать цифры. HR приносит штатное расписание в Excel. Консультанты просят уточнить функции. Директора хотят отдельно проработать свои ветки.

И здесь инструмент либо помогает, либо мешает (если разработчик его ограничил).

От Инструмента мне нужны были четыре вещи.

Во-первых, легко выгрузить наработанное в машиночитаемый формат.

Не просто картинку. Не скриншот. Не закрытый файл, который открывается только в одной программе. А нормальную структуру, которую можно передать дальше.

Во-вторых, продолжить работу локально.

В таких моделях часто есть чувствительные коммерческие и персональные данные: ФИО, бюджеты, штат, зарплатные гипотезы, будущие назначения, сделки, планы объединения активов. Не всегда хочется отправлять всё это в очередное облако.

В-третьих, использовать свой AI.

Это на практике одна из самых важных возможностей.

У компании уже может быть AI-чат, где обсуждалась стратегия, миссия, штатное расписание, вводные по M&A, продуктовая линейка, финансовые ограничения и конфликтные точки.

Значит, логично не встраивать в редактор очередной API-агент, а дать пользователю машиночитаемую модель.

Пользователь может отправить ORGF-файл в свой AI и попросить:

После этого обновлённую модель можно снова открыть в Studio и смотреть уже визуально.

В-четвёртых, нужно уметь объединять части модели.

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

Если формат открыт и машиночитаем, это становится нормальной задачей. В том числе для AI.

В итоге я сформулировал для себя набор требований и реализовал их в ORGFORMAT Studio.

Инструмент должен:

ORGFORMAT состоит из двух частей.

Первая — открытый формат файла `.orgf`. Он описан, опубликован и может использоваться отдельно от Studio.

Вторая — бесплатный редактор ORGFORMAT Studio, где эти модели можно открывать, редактировать и презентовать.

Я вижу несколько сценариев, где такой инструмент особенно нужен.

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

M&A. Когда после покупки активов надо совместить несколько разных структур, убрать дубли, разнести ответственность и понять, где будет будущая операционная логика.

Оргтрансформация. Когда компания переходит от персональной модели управления к функциональной, продуктовой или кластерной.

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

Защита новой модели перед собственниками. Когда важно не просто показать красивую схему, а пройти по каждой ветке и объяснить её value, ответственность, признаки и риски.

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

Я не утверждаю, что ORGFORMAT заменяет HRIS, ERP, BPM, ARIS или полноценные корпоративные системы.

И не должен заменять.

Это другой слой.

Лёгкий слой моделирования перед тем, как решение попадёт в тяжёлые системы, регламенты, штатные расписания, бюджеты и приказы.

Сначала надо договориться о модели.

Потом уже её внедрять.

Для меня ORGFORMAT — это попытка вернуть оргструктуре статус рабочей модели.

Не картинки для презентации.

Не файла, который живёт только в одной программе.

Не статичного приложения к приказу.

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

Мне интересно, как вы сейчас решаете похожие задачи.

Чем моделируете As Is / To Be?

Где храните признаки: ФИО, юрлица, PAEI, бюджеты, статусы?

Считаете ли value по веткам или всё остаётся в Excel отдельно от схемы?

И можно ли сегодня вообще говорить о VAD в оргструктурах без драки с процессными методологами?

Буду рад критике, примерам и спорам в комментариях.

ORGFORMAT Studio можно попробовать бесплатно:

https://orgformat.com/studio/

Открытый формат ORGF и описание:

https://github.com/orgformat/orgf

Демо-модель по оргтрансформации / Адизесу:

https://orgformat.com/ru/professional/cases/adizes-org-design.html