Алексей пришёл с распечаткой. Двенадцать страниц — схемы, стрелки, блоки с латинскими аббревиатурами. Он провёл три месяца с консультантом, который «внедрял современный западный фреймворк управления». Фреймворк назывался красиво. Схемы выглядели убедительно. Компания стояла.
Не падала — именно стояла. Как вкопанная.
Я спросил: «Что конкретно изменилось за три месяца?» Алексей помолчал. Потом сказал примерно следующее: «Мы стали правильно называть совещания».
Вот с этого и начнём.
Алексей — собственник производственного бизнеса. Больше десяти лет в отрасли, оборот под полмиллиарда, несколько сотен сотрудников. Не стартап, не история про «поднялись с нуля за два года». Зрелый бизнес с выстроенными процессами — по крайней мере, так казалось снаружи.
Изнутри картина была другой. Алексей работал по двенадцать часов в день и при этом чувствовал, что компания держится на нём как на гвозде. Уйди он в отпуск на две недели — и что-нибудь обязательно сломается. Не потому что команда плохая. Потому что все ключевые решения — даже мелкие — шли через него.
Он слышал про «системный менеджмент», про «делегирование», про «выход из операционки». Читал книги. Смотрел выступления. В какой-то момент решил: нужен консультант, который внедрит конкретный инструмент. Не теорию — практику.
Консультант нашёлся быстро. Привёз фреймворк — западную методологию управления, адаптированную «под российский рынок». Три месяца работы, несколько сессий с командой, красивые схемы. На выходе — новая терминология для старых проблем и совещания с правильными названиями.
Алексей не был разочарован в консультанте. Он был разочарован в себе: потратил время и деньги, а воз и ныне там. Именно в этой точке он пришёл ко мне.
Но три месяца спустя после нашей первой встречи стало понятно: проблема была не в консультанте и не в фреймворке.
На поверхности запрос звучал так: «Фреймворк не работает. Хочу понять почему — и что делать дальше».
Это честный запрос. Но он описывал симптом, а не болезнь.
Я попросил Алексея рассказать не про фреймворк, а про то, как устроена компания. Кто принимает какие решения. Что происходит, когда он не отвечает на звонок два часа. Как менеджеры ведут себя на планёрках — говорят или молчат. Что случается, когда что-то идёт не по плану.
За час разговора обнаружились три структурные проблемы.
Первая. Все решения — включая те, которые формально делегированы, — в итоге возвращались к Алексею. Не потому что он не доверял команде. Потому что команда привыкла: если подождать, собственник решит сам. Это удобнее, чем брать ответственность.
Вторая. Менеджеры не принимали ответственность — не из-за некомпетентности, а из-за отсутствия договорённостей. Никто не знал точно, где заканчиваются его полномочия и начинаются чужие. Фреймворк описал эти зоны красивыми словами, но не зафиксировал их письменно и не проверил, понял ли каждый, что именно от него ожидается.
Третья. Горизонт планирования в компании — следующая неделя. Иногда следующий месяц. Стратегический разговор о том, куда движется бизнес через год, не происходил вообще. Не потому что Алексей не думал об этом — думал, постоянно. Но думал в одиночку.
Фреймворк не решал ни одну из этих проблем. Он описывал их другими словами. Это не плохо — диагностика важна. Но диагностика — не лечение.
Настоящая проблема оказалась в другом месте: в том, что никто не задал вопрос «а что именно мы меняем и в каком порядке?»
Дальше начались выборы. Каждый из них мог пойти иначе — и результат был бы другим.
Развилка первая: выбросить фреймворк или адаптировать.
Первый импульс Алексея — выбросить. Три месяца потрачены, результата нет, зачем тащить дальше. Я предложил другое: посмотреть, что в фреймворке реально работает, а что — красивая обёртка.
Мы разобрали методологию по частям. Из семи инструментов два оказались полезными в том виде, в котором они были. Остальные пять либо не подходили под структуру этого бизнеса, либо требовали условий, которых не было: зрелой HR-функции, формализованных процессов, определённого уровня доверия внутри команды.
Взяли два. Остальное убрали. Это сразу сняло напряжение — команда перестала чувствовать, что на неё навешивают чужую систему.
Развилка вторая: начать с процессов или с людей.
Логика фреймворков обычно такая: сначала описываем процессы, потом под них подбираем людей или переучиваем существующих. Это работает в больших компаниях с выстроенной HR-функцией.
В МСБ — чаще наоборот. Процессы меняются быстро, люди остаются. Если начать с процессов, через полгода окажется, что они описывают то, как должно быть, а не то, как есть.
Мы начали с людей. Три ключевых менеджера — разговор с каждым отдельно. Не про фреймворк, не про методологию. Про то, что они реально делают, что им мешает, где они чувствуют, что их полномочия заканчиваются там, где должны начинаться. Потом — письменные договорённости. Не должностные инструкции, а конкретные: «ты принимаешь решения вот в этих ситуациях, вот до этой суммы, вот с этими людьми в копии».
Это заняло три недели. Скучная работа. Никаких схем.
Развилка третья: темп изменений.
Алексей хотел быстро. Это понятно — он уже потратил три месяца, хотелось результата. Я предложил медленно, но необратимо.
Быстрые изменения в МСБ почти всегда откатываются. Команда адаптируется к новым словам, но не меняет поведение. Через два месяца всё возвращается на круги своя, только с новой терминологией.
Медленный темп — это значит: одно изменение за раз. Дождаться, пока оно стало привычкой, прежде чем вводить следующее. Проверить, что менеджер действительно принял решение самостоятельно — не потому что Алексей был недоступен, а потому что понял: это его зона.
Алексей согласился неохотно. Это оказалось решающим выбором.
Третья развилка едва не сломала всё — в середине работы Алексей несколько раз порывался ускориться. Каждый раз мы возвращались к договорённости: медленно, но необратимо.
Через семь месяцев Алексей вышел из операционки примерно на шестьдесят процентов. Это не полный выход — и не планировалось. Это точка, в которой он перестал быть узким местом в рутинных решениях.
Конкретно: три решения в неделю вместо тридцати. Команда научилась работать без него в стандартных ситуациях. Появился горизонт планирования на квартал — не идеальный, но существующий. Алексей впервые за несколько лет взял отпуск на десять дней. Компания не сломалась.
Это победа. Но не чистая.
Один из трёх ключевых менеджеров не справился с новой ролью. Не потому что он плохой специалист — он отличный исполнитель. Но роль, в которой нужно принимать самостоятельные решения и нести за них ответственность, оказалась не его. Это выяснилось не сразу — потребовалось четыре месяца, чтобы стало очевидным.
Расстались. Это было болезненно для Алексея — человек работал в компании много лет. И это не было предсказано заранее: я не сказал ему в начале «один из трёх уйдёт». Мог бы сказать — вероятность была высокой. Не сказал, потому что не хотел создавать предубеждение. Это моё решение, и я не уверен, что оно было правильным.
Один незапланированный результат оказался болезненным. Остальные — нет.
Это четвёртый раз за последние два года, когда я вижу одну и ту же структуру. Собственник зрелого МСБ. Операционная перегрузка. Решение — внедрить методологию. Методология внедрена. Проблема осталась.
Паттерн не в том, что западные фреймворки плохие. Они хорошие. Проблема в том, как их применяют.
Фреймворк — это язык, а не инструкция. Он даёт слова для описания проблем. Но слова не решают проблемы — их решают конкретные действия конкретных людей в конкретной структуре власти.
В западных компаниях, для которых создавались эти методологии, есть несколько условий, которых в российском МСБ обычно нет. Формализованные процессы. HR-функция, способная поддержать изменения. Команда, привыкшая к письменным договорённостям. Культура, в которой «я не знаю» — допустимый ответ на совещании.
Когда фреймворк переносится без адаптации, он описывает желаемое состояние, а не путь к нему. Это полезно для диагностики. Бесполезно для изменений.
Что работает в российском МСБ — по моему опыту:
Адаптация под конкретную структуру власти в компании. Не «как должно быть по методологии», а «как устроена власть здесь и что из этого следует». В каждом бизнесе своя карта — кто реально принимает решения, кто влияет, кто блокирует.
Начало с людей, а не с процессов. Процессы меняются быстро. Люди — медленно. Если начать с людей, процессы подстроятся. Наоборот — редко.
Медленный темп. Одно изменение за раз. Дождаться необратимости.
Письменные договорённости вместо схем. Схема — это картинка. Договорённость — это обязательство. В МСБ работают обязательства.
Здесь обычно возникает возражение: «У нас не западный фреймворк, у нас своя система». Отвечу так: структура проблемы не зависит от названия системы. Если решения замкнуты на собственнике, команда не принимает ответственность, а горизонт планирования — следующая неделя — это одна и та же проблема, как её ни называй.
Это единичный случай или типичная ситуация для МСБ?
Типичная. За последние два года я видел эту структуру четыре раза в разных отраслях. Детали разные — производство, IT-сервис, розница. Суть одна: методология внедрена, поведение не изменилось. Это не случайность, это паттерн.
А если фреймворк уже внедрён и команда к нему привыкла — стоит ли его менять?
Зависит от того, что именно внедрено. Если терминология прижилась и люди говорят на одном языке — это ценно, не трогайте. Если под терминологией нет изменений в поведении — нужно разбираться, что именно не работает, и менять это, а не весь фреймворк целиком.
Что делать, если я вижу у себя похожую ситуацию?
Начать с диагностики: не «какой фреймворк внедрить», а «где конкретно застревают решения и почему». Это можно сделать самостоятельно — поговорить с тремя-четырьмя ключевыми людьми в компании и задать им один вопрос: «Что мешает тебе принимать решения без меня?» Ответы обычно неожиданные.
Двенадцать страниц схем лежат у многих. Не потому что консультанты плохие — потому что схемы легче сделать, чем изменить поведение людей.
Если в этом кейсе ты узнал свою структуру — не обязательно про фреймворк, достаточно сходства по сути: решения замкнуты на тебе, команда не тянет ответственность, горизонт планирования — следующая неделя — приходи на разбор.
Работаю с собственниками бизнесов от 80 миллионов выручки. Беру не больше двух новых запросов в месяц. Формат первого разговора — 20 минут, без продаж, только диагностика.
Напиши на hi@vvetrov.com: кто ты, что за бизнес, в чём вопрос.
Если ты читаешь это и думаешь «у меня другое, у меня своя система» — возможно, так и есть. Но структура проблемы, как правило, одна. Подожди, пока станет очевидным — или не жди.
P.S. Двенадцать страниц схем — это не плохо. Это просто не то, с чего начинают.
Апрель 2026. Автор — Виталий Ветров, управляющий партнёр юридической фирмы и стратегический советник.
По теме: Фреймворк X: пошаговый разбор для МСБ — теоретическая база к этому кейсу. Выход из операционки за 6 месяцев: кейс производственной компании — смежный кейс со схожей структурой проблемы. Что взять из западных методологий для IT-компании — тот же вопрос в другой отрасли.