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

Фреймворк X выглядит как готовый ответ. Красивая схема, логичная последовательность, кейсы из американских учебников — всё на месте. Российские собственники берут его, запускают, и половина бросает через три месяца. Не потому что плохой инструмент. Потому что применяют его так, как написано в оригинале — а оригинал писался для другого контекста, другой команды и другого горизонта планирования.

В этом тексте — что именно ломается при переносе фреймворка X в российский МСБ, что можно адаптировать, что нужно выбросить, и как это выглядело в реальной работе с собственниками. Не теория. Практика применения западных управленческих методологий в условиях, которые их авторы не предполагали.

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

1. Что такое фреймворк X и почему он попал в Россию 2. Три точки, где фреймворк ломается в российском МСБ 3. Как это выглядело в реальной работе: кейс первый 4. Что реально работает: адаптированная логика применения 5. Когда адаптация не спасает: кейс второй 6. Как принять решение — брать фреймворк X или нет 7. Частые вопросы

Фреймворк X — это не один конкретный инструмент. Это собирательное название для класса западных управленческих методологий, которые появились в МСБ-повестке российских собственников примерно в 2018–2022 годах: OKR, EOS, Scaling Up, Mochary Method, различные вариации agile-подходов для нетехнических команд. Их объединяет одно: они созданы для компаний с горизонтальной культурой, зрелыми процессами и командами, которые умеют работать с абстракциями.

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

Прежде чем читать дальше — вспомни последний управленческий инструмент, который ты брал «как написано». Что произошло через три месяца?

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

Это не проблема людей. Это проблема контекста. И именно здесь начинается настоящий разговор.

Пятый раз за квартал вижу одну и ту же картину: собственник приходит с фреймворком в руках, горящими глазами — и командой, которая смотрит на него с вежливым непониманием.

Ломается не случайно и не в разных местах у разных людей. Ломается в трёх точках — почти всегда.

Первая точка: принятие решений — не корпоративное, а личное.

Большинство западных фреймворков предполагают, что решения принимаются через процедуру. Есть встреча, есть повестка, есть голосование или консенсус. В российском МСБ решения принимает собственник — часто в коридоре, часто на основе интуиции, часто без документации. Это не патология. Это адаптация к среде, где процедура медленнее, чем рынок.

Фреймворк X, встроенный поверх этой реальности, создаёт двойную систему: формальную (по фреймворку) и реальную (как было). Команда быстро понимает, какая из них настоящая.

Вторая точка: горизонт планирования.

OKR рассчитан на квартальные циклы с годовой стратегией. Scaling Up — на трёхлетние горизонты. Российский МСБ в 2024–2026 году живёт в режиме, где горизонт уверенного планирования — три-четыре месяца. Не потому что собственники не умеют думать стратегически. Потому что внешняя среда не даёт более длинного окна без существенной неопределённости.

Здесь обычно возникает возражение: «У нас специфика, это не подойдёт». Это обоснованное возражение. Но оно неточно сформулировано. Подходит — но не целиком. Квартальный цикл работает. Годовая стратегия в жёстком виде — нет. Это разные части одного инструмента, и их можно разделить.

Третья точка: команда — не ресурс, а история отношений.

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

Фреймворк X, который работает с ролями, игнорирует эту ткань. И рвётся о неё.

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

> Если хочешь следить за такими разборами — в Telegram выходит регулярно: практика, кейсы, инструменты без инфобизнеса. t.me/vvetrov

Андрей — собственник производственной компании в регионе, выручка около 200 миллионов, 60 человек в штате, бизнес существует 12 лет. Пришёл с запросом: «Хочу внедрить OKR, читал книгу, кажется, это то, что нам нужно».

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

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

Что сделали вместо: взяли только один элемент OKR — еженедельный check-in на приоритеты. Без квартальных целей, без каскадирования, без всей архитектуры. Просто: «Что три главных вещи на эту неделю, и как они связаны с тем, что мы решили месяц назад?»

Через два месяца топ-менеджеры начали говорить на одном языке. Не потому что внедрили OKR. Потому что появился ритм совместного осмысления приоритетов — без названия и без методологии.

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

Это не значит, что OKR плохой инструмент. Это значит, что инструмент и принцип — разные вещи. И иногда нужен только принцип.

После нескольких лет работы с фреймворком X в российском МСБ у меня сложилась рабочая схема: что сохранять, что переписывать, что выбрасывать.

Что сохраняется без изменений.

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

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

Что нужно переписать.

Горизонт. Квартал — рабочий. Год в жёстком виде — нет. Я работаю с «мягким годом»: направление на 12 месяцев формулируется как намерение, не как обязательство. Это снижает тревогу и повышает честность в планировании.

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

Здесь обычно возникает возражение: «Мы уже пробовали похожее — не работает». Это почти всегда означает: пробовали инструмент, не пробовали принцип. Или пробовали принцип без ритма. Или с ритмом, но без ответственности. Это разные вещи.

Что выбросить совсем.

Каскадирование целей вниз по иерархии. В МСБ с командой до 100 человек это создаёт бюрократию без пользы. Цели собственника и цели линейного сотрудника — разные уровни абстракции. Попытка их связать через методологию тратит время и создаёт иллюзию согласованности.

Публичные дашборды с прогрессом. В корпоративной культуре это работает как инструмент прозрачности. В МСБ с личными отношениями — как инструмент давления и стыда. Люди начинают управлять метриками, а не работой.

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

Это точная метафора. И она подводит к вопросу: а что если костюм не твоего размера вообще?

Марина — собственник сервисного бизнеса, выручка около 120 миллионов, команда 25 человек, бизнес восемь лет. Пришла с похожим запросом: хочет выйти из операционки, нужна система.

Мы адаптировали фреймворк X по всем правилам: убрали лишнее, переписали язык, поставили ритм. Через квартал стало ясно, что ничего не меняется. Не потому что инструмент плохой или адаптация неверная.

Потому что проблема была не в отсутствии системы.

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

Фреймворк X не мог помочь, потому что он отвечал на вопрос, который не был настоящим вопросом.

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

Иногда правильный ответ на «какой фреймворк мне нужен» — это «никакой». Не потому что фреймворки плохие. Потому что вопрос сформулирован неточно.

Три вопроса для диагностики. Я задаю их до того, как мы вообще обсуждаем конкретный инструмент.

Первый: что именно не работает сейчас?

Не «хочу систему» и не «хочу выйти из операционки». А конкретно: что происходит, что тебя не устраивает, в какой момент ты это замечаешь. Если ответ размытый — фреймворк не поможет. Он структурирует то, что уже есть. Если нет ясности в проблеме, структура её не создаст.

Второй: есть ли у тебя человек, который будет держать ритм?

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

Третий: готов ли ты к тому, что инструмент покажет неудобное?

Хороший фреймворк делает видимым то, что было невидимым. Иногда это приятно. Часто — нет. Если собственник не готов к тому, что система покажет, например, что проблема не в команде, а в нём самом — лучше не начинать.

Здесь обычно возникает возражение: «Это дорого и сложно внедрять». Это не про деньги. Это про готовность. Дорого — это когда внедрили, потратили время команды, и бросили через три месяца. Вот это дорого.

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

Признаки, что нет: проблема размытая, ритм некому держать, фреймворк берётся «потому что все берут», или потому что «надо навести порядок» — без понимания, какой именно порядок и зачем.

Если нет — это не конец разговора. Это начало другого разговора. О том, что на самом деле нужно.

И вот тот вопрос, который я обещал в начале. Я задаю его до любого разговора о фреймворках: «Если через год всё будет так, как ты хочешь — как будет выглядеть твой обычный вторник?» Не стратегия, не цифры, не структура. Вторник.

Половина собственников не могут ответить. И это важнее любого фреймворка.

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

Вопрос поставлен неточно. Для команды до 30 человек чаще всего не нужен полный фреймворк — нужен один принцип из него. Обычно это ритм (еженедельная встреча с одной структурой) плюс приоритизация (три главных вещи на период). Этого достаточно для 80% задач, с которыми приходят собственники такого размера.

Сопротивление команды почти всегда означает одно из двух: либо люди не понимают, зачем это нужно (проблема коммуникации), либо они понимают лучше собственника, что инструмент не решает реальную проблему (проблема диагностики). Первое лечится объяснением. Второе — стоит услышать.

В начале я написал, что фреймворк X выглядит как готовый ответ. Теперь понятно, почему это опасная иллюзия — и как из неё выйти. Не потому что инструмент плохой. Потому что готовых ответов на управленческие вопросы не существует. Есть принципы, которые работают в любом контексте. Есть инструменты, которые нужно адаптировать. И есть вопросы, которые нужно задать до того, как брать любой инструмент.

Если хочешь разобраться, как западные управленческие методологии работают в российском МСБ — начни с разбора Mochary Method в российских реалиях или с материала что взять из западных методологий для B2B-услуг. Там другие углы той же темы.

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

Беру не больше трёх новых клиентов в квартал. Если интересно — напиши на hi@vvetrov.com: кто ты, что за бизнес, какой вопрос. Я отвечу честно: подхожу или нет.

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

P.S. Если не подхожу — скажу, куда идти.

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