Фреймворк X: применение в практике российского МСБ: практика советника

Алексей пришёл с распечаткой. Двенадцать страниц — схемы, стрелки, блоки с латинскими аббревиатурами. Он провёл три месяца с консультантом, который «внедрял современный западный фреймворк управления». Фреймворк назывался красиво. Схемы выглядели убедительно. Компания стояла.

Не падала — именно стояла. Как вкопанная.

Я спросил: «Что конкретно изменилось за три месяца?» Алексей помолчал. Потом сказал примерно следующее: «Мы стали правильно называть совещания».

Вот с этого и начнём.

Алексей — собственник производственного бизнеса. Больше десяти лет в отрасли, оборот под полмиллиарда, несколько сотен сотрудников. Не стартап, не история про «поднялись с нуля за два года». Зрелый бизнес с выстроенными процессами — по крайней мере, так казалось снаружи.

Изнутри картина была другой. Алексей работал по двенадцать часов в день и при этом чувствовал, что компания держится на нём как на гвозде. Уйди он в отпуск на две недели — и что-нибудь обязательно сломается. Не потому что команда плохая. Потому что все ключевые решения — даже мелкие — шли через него.

Он слышал про «системный менеджмент», про «делегирование», про «выход из операционки». Читал книги. Смотрел выступления. В какой-то момент решил: нужен консультант, который внедрит конкретный инструмент. Не теорию — практику.

Консультант нашёлся быстро. Привёз фреймворк — западную методологию управления, адаптированную «под российский рынок». Три месяца работы, несколько сессий с командой, красивые схемы. На выходе — новая терминология для старых проблем и совещания с правильными названиями.

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

Но три месяца спустя после нашей первой встречи стало понятно: проблема была не в консультанте и не в фреймворке.

На поверхности запрос звучал так: «Фреймворк не работает. Хочу понять почему — и что делать дальше».

Это честный запрос. Но он описывал симптом, а не болезнь.

Я попросил Алексея рассказать не про фреймворк, а про то, как устроена компания. Кто принимает какие решения. Что происходит, когда он не отвечает на звонок два часа. Как менеджеры ведут себя на планёрках — говорят или молчат. Что случается, когда что-то идёт не по плану.

За час разговора обнаружились три структурные проблемы.

Первая. Все решения — включая те, которые формально делегированы, — в итоге возвращались к Алексею. Не потому что он не доверял команде. Потому что команда привыкла: если подождать, собственник решит сам. Это удобнее, чем брать ответственность.

Вторая. Менеджеры не принимали ответственность — не из-за некомпетентности, а из-за отсутствия договорённостей. Никто не знал точно, где заканчиваются его полномочия и начинаются чужие. Фреймворк описал эти зоны красивыми словами, но не зафиксировал их письменно и не проверил, понял ли каждый, что именно от него ожидается.

Третья. Горизонт планирования в компании — следующая неделя. Иногда следующий месяц. Стратегический разговор о том, куда движется бизнес через год, не происходил вообще. Не потому что Алексей не думал об этом — думал, постоянно. Но думал в одиночку.

Фреймворк не решал ни одну из этих проблем. Он описывал их другими словами. Это не плохо — диагностика важна. Но диагностика — не лечение.

Настоящая проблема оказалась в другом месте: в том, что никто не задал вопрос «а что именно мы меняем и в каком порядке?»

Дальше начались выборы. Каждый из них мог пойти иначе — и результат был бы другим.

Развилка первая: выбросить фреймворк или адаптировать.

Первый импульс Алексея — выбросить. Три месяца потрачены, результата нет, зачем тащить дальше. Я предложил другое: посмотреть, что в фреймворке реально работает, а что — красивая обёртка.

Мы разобрали методологию по частям. Из семи инструментов два оказались полезными в том виде, в котором они были. Остальные пять либо не подходили под структуру этого бизнеса, либо требовали условий, которых не было: зрелой HR-функции, формализованных процессов, определённого уровня доверия внутри команды.

Взяли два. Остальное убрали. Это сразу сняло напряжение — команда перестала чувствовать, что на неё навешивают чужую систему.

Развилка вторая: начать с процессов или с людей.

Логика фреймворков обычно такая: сначала описываем процессы, потом под них подбираем людей или переучиваем существующих. Это работает в больших компаниях с выстроенной HR-функцией.

В МСБ — чаще наоборот. Процессы меняются быстро, люди остаются. Если начать с процессов, через полгода окажется, что они описывают то, как должно быть, а не то, как есть.

Мы начали с людей. Три ключевых менеджера — разговор с каждым отдельно. Не про фреймворк, не про методологию. Про то, что они реально делают, что им мешает, где они чувствуют, что их полномочия заканчиваются там, где должны начинаться. Потом — письменные договорённости. Не должностные инструкции, а конкретные: «ты принимаешь решения вот в этих ситуациях, вот до этой суммы, вот с этими людьми в копии».

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

Развилка третья: темп изменений.

Алексей хотел быстро. Это понятно — он уже потратил три месяца, хотелось результата. Я предложил медленно, но необратимо.

Быстрые изменения в МСБ почти всегда откатываются. Команда адаптируется к новым словам, но не меняет поведение. Через два месяца всё возвращается на круги своя, только с новой терминологией.

Медленный темп — это значит: одно изменение за раз. Дождаться, пока оно стало привычкой, прежде чем вводить следующее. Проверить, что менеджер действительно принял решение самостоятельно — не потому что Алексей был недоступен, а потому что понял: это его зона.

Алексей согласился неохотно. Это оказалось решающим выбором.

Третья развилка едва не сломала всё — в середине работы Алексей несколько раз порывался ускориться. Каждый раз мы возвращались к договорённости: медленно, но необратимо.

Через семь месяцев Алексей вышел из операционки примерно на шестьдесят процентов. Это не полный выход — и не планировалось. Это точка, в которой он перестал быть узким местом в рутинных решениях.

Конкретно: три решения в неделю вместо тридцати. Команда научилась работать без него в стандартных ситуациях. Появился горизонт планирования на квартал — не идеальный, но существующий. Алексей впервые за несколько лет взял отпуск на десять дней. Компания не сломалась.

Это победа. Но не чистая.

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

Расстались. Это было болезненно для Алексея — человек работал в компании много лет. И это не было предсказано заранее: я не сказал ему в начале «один из трёх уйдёт». Мог бы сказать — вероятность была высокой. Не сказал, потому что не хотел создавать предубеждение. Это моё решение, и я не уверен, что оно было правильным.

Один незапланированный результат оказался болезненным. Остальные — нет.

Это четвёртый раз за последние два года, когда я вижу одну и ту же структуру. Собственник зрелого МСБ. Операционная перегрузка. Решение — внедрить методологию. Методология внедрена. Проблема осталась.

Паттерн не в том, что западные фреймворки плохие. Они хорошие. Проблема в том, как их применяют.

Фреймворк — это язык, а не инструкция. Он даёт слова для описания проблем. Но слова не решают проблемы — их решают конкретные действия конкретных людей в конкретной структуре власти.

В западных компаниях, для которых создавались эти методологии, есть несколько условий, которых в российском МСБ обычно нет. Формализованные процессы. HR-функция, способная поддержать изменения. Команда, привыкшая к письменным договорённостям. Культура, в которой «я не знаю» — допустимый ответ на совещании.

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

Что работает в российском МСБ — по моему опыту:

Адаптация под конкретную структуру власти в компании. Не «как должно быть по методологии», а «как устроена власть здесь и что из этого следует». В каждом бизнесе своя карта — кто реально принимает решения, кто влияет, кто блокирует.

Начало с людей, а не с процессов. Процессы меняются быстро. Люди — медленно. Если начать с людей, процессы подстроятся. Наоборот — редко.

Медленный темп. Одно изменение за раз. Дождаться необратимости.

Письменные договорённости вместо схем. Схема — это картинка. Договорённость — это обязательство. В МСБ работают обязательства.

Здесь обычно возникает возражение: «У нас не западный фреймворк, у нас своя система». Отвечу так: структура проблемы не зависит от названия системы. Если решения замкнуты на собственнике, команда не принимает ответственность, а горизонт планирования — следующая неделя — это одна и та же проблема, как её ни называй.

Это единичный случай или типичная ситуация для МСБ?

Типичная. За последние два года я видел эту структуру четыре раза в разных отраслях. Детали разные — производство, IT-сервис, розница. Суть одна: методология внедрена, поведение не изменилось. Это не случайность, это паттерн.

А если фреймворк уже внедрён и команда к нему привыкла — стоит ли его менять?

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

Что делать, если я вижу у себя похожую ситуацию?

Начать с диагностики: не «какой фреймворк внедрить», а «где конкретно застревают решения и почему». Это можно сделать самостоятельно — поговорить с тремя-четырьмя ключевыми людьми в компании и задать им один вопрос: «Что мешает тебе принимать решения без меня?» Ответы обычно неожиданные.

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

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

Работаю с собственниками бизнесов от 80 миллионов выручки. Беру не больше двух новых запросов в месяц. Формат первого разговора — 20 минут, без продаж, только диагностика.

Напиши на hi@vvetrov.com: кто ты, что за бизнес, в чём вопрос.

Если ты читаешь это и думаешь «у меня другое, у меня своя система» — возможно, так и есть. Но структура проблемы, как правило, одна. Подожди, пока станет очевидным — или не жди.

P.S. Двенадцать страниц схем — это не плохо. Это просто не то, с чего начинают.

Апрель 2026. Автор — Виталий Ветров, управляющий партнёр юридической фирмы и стратегический советник.

По теме: Фреймворк X: пошаговый разбор для МСБ — теоретическая база к этому кейсу. Выход из операционки за 6 месяцев: кейс производственной компании — смежный кейс со схожей структурой проблемы. Что взять из западных методологий для IT-компании — тот же вопрос в другой отрасли.