Когда структура строится на зависимости: четыре критерия, которые нельзя игнорировать.
Оргструктура — это не просто схема, а способ учесть связи между людьми и задачами. Но если не понять, какие зависимости важны — организацию разорвёт на куски.
📦 Кейс
Когда в компании внедряли CRM, Владимир столкнулся с неожиданным конфликтом. Отдел продаж просил техподдержку настроить шаблоны документов, логистика — интеграцию с маршрутами, а отдел закупок — загрузку остатков. Вроде бы все хотели одного — работать быстрее. Но началась война.
Техподдержка захлёбывалась в заявках. Продажи кричали, что «им важнее», логистика жаловалась на «дилетантов», которые не понимают процессов. В кулуарах обсуждали: «А что вообще делает этот ИТ-отдел, если он никому не помогает?»
Всё обострилось, когда CRM «сломалась» — а точнее, один отдел обновил модуль, не предупредив другие. Отгрузки сорвались, клиенты злились. Владимир созвал экстренное совещание.
Оказалось: ИТ служба подчиняется коммерческому директору, который вообще не в курсе, как выглядят рабочие потоки в логистике. А техподдержка — одна на всех. В структуре не было учтено, что ИТ работает в условиях взаимной зависимости с каждым отделом.
Именно тогда Владимир впервые услышал термин: «Зависимость как критерий группировки». Что из этого вышло — расскажу ниже.
🧱 Разбор
Вы не можете группировать роли и команды вслепую. Органиграмма — это не шахматная доска. Это отражение того, как люди взаимодействуют, зависят друг от друга, и кто с кем должен быть на связи каждую неделю.
В теории оргдизайна есть четыре типа зависимости, которые стоит учитывать перед тем, как объединять или разделять команды. Пройдемся по ним.
1. Зависимости рабочего потока
Если один человек заканчивает, а другой начинает — это последовательная зависимость. Если они работают над одним продуктом, в одном моменте времени — это взаимная. Если просто пользуются одними ресурсами — коллективная.
💡 Что это значит для структуры?
- Если есть взаимная зависимость — людей нужно объединять в один отдел.
- Если последовательная — можно строить иерархию: один отдел передаёт результат другому.
- Если только общие ресурсы — можно и не объединять, но надо управлять доступом.
Пример: логист и сборщик — завязаны друг на друга. Если они в разных отделах, проблемы будут всплывать каждый день. А если в одном — договариваются на месте.
2. Зависимости процессов
Это про схожесть технологий, инструментов, языка. Два программиста могут работать на разных проектах, но им будет проще советоваться друг с другом, чем с бухгалтером.
💡 Что это значит для структуры?
- Людей со схожими процессами стоит объединять — это усиливает обучение, повышает экспертизу.
- Это — аргумент за функциональное группирование: когда маркетологи с маркетологами, инженеры с инженерами.
- Но есть риск: при этом может пострадать логика по продукту или по клиенту.
Пример: Александр пытался «вшить» ИТ-специалиста в каждый отдел. Но ИТшник тратил больше времени на объяснение своих задач, чем на работу. Когда собрали их всех в одну команду — стали развиваться быстрее.
3. Зависимости масштаба
Иногда задача слишком мала или слишком велика для того, чтобы выполнять её в каждом отделе отдельно. Это и есть эффект масштаба.
💡 Что это значит для структуры?
- Специалистов узкого профиля стоит объединять в централизованные службы.
- Вопрос в балансе: не сделать их «узким горлышком», но и не плодить дублирующих функций.
Пример: в каждом филиале просили «своего бухгалтера». Но держать по одному — неэффективно. Александр ввёл единую службу бухгалтерии с чётким SLA для всех регионов.
4. Социальные зависимости
Это про людей, а не задачи. Кто с кем «ладит», где возникает чувство команды, как распределяется социальная энергия. Игнорировать это — значит получить саботаж даже при логичной структуре.
💡 Что это значит для структуры?
- Люди работают лучше с теми, кому доверяют. Иногда это важнее, чем поток задач.
- Не всё измеряется в Excel. Учитывайте неформальные связи, особенно при создании проектных команд.
Пример: один из филиалов у Александра работал хуже всех. Выяснилось — коллектив токсичный, не было ни одного связующего человека. После замены двух «ядовитых» сотрудников — производительность выросла.
📘 Суть инструмента
Что учитывать при проектировании структуры:
- Рабочий поток — кто от кого зависит в производстве результата?
- Процессы — кто работает с одинаковыми инструментами и методами?
- Масштаб — какие функции нужно централизовать, а какие можно размазать?
- Люди — кто с кем может договариваться без приказа сверху?
Почему это важно:
- Структура без учёта этих зависимостей — как схема водопровода без давления: трубы есть, а вода не идёт.
- Игнорирование одной зависимости ради другой — это компромисс, но он должен быть осознанным, а не случайным.
✅ Что стало с компанией
Владимир пересобрал ИТ-службу как отдельную кросс-функциональную команду. Вместо попытки «раздать по чуть-чуть» он выстроил систему приоритетов и регулярных стыков с каждым отделом. CRM снова заработала. Коммуникации упростились. А главное — снизилось количество конфликтов и срывов задач. Люди почувствовали, что внутри структуры кто-то реально думает об их зависимости от других.
📌 Памятка
- Не объединяй роли просто потому, что так удобно рисовать.
- Учитывай: кто от кого зависит, кто с кем должен говорить каждый день.
- Масштаб — не всегда про экономию, иногда про фокус.
- За структурой всегда стоят люди. Игнорируешь это — получаешь сопротивление.
- Каждое подразделение — это компромисс между логикой работы и логикой отношений.
❓ Контрольные вопросы
- Есть ли у тебя сегодня роли, которые по сути не могут работать без других, но сидят в разных отделах?
- Кто у тебя в компании объединён «по названию», но не по процессу?
- Где в структуре ты чувствуешь трение, которое не объясняется KPI?
🔜 Чем дополнить
А как вообще выбрать, чему отдавать приоритет: логике продукта или логике функции?