Дисклеймер:
Основано на методике ЦРУ, рассекреченой в 2008 г.
Осторожно, не пытайтесь повторить, выполнено профессионалами.
В моем курсе "Принятие решений" есть такая тема, "Принятие", где я рассматриваю темы антогонисты: споры и убийцы решений. И вот в развитие темы я часто публикую разные находки, которые попадаются чтоб потом собрать все в единый учебник или сборник методов. И вот встретилась мне концепция "саботажа решений" (спасибо рассекреченой методике ЦРУ 1944 г.), и я решил подвести некоторую теоретическую основу концепции саботажа.
Методика опирается на три закона, три принципа и три правила. Они не прописаны явно в документе, но они бы украсили и дали повод для дискуссий, исследований и новых открытий.
Идея очень проста: если решение в организации затрагивает ваши интересы, то его (это решение) надо убить, отклонить или саботировать. Инструментов и убийц решений много (20 классических и 20 New), а вот саботаж и дезорганизацию мы как то упустили из вида, как возможность влиять на решения. Итак, разберем:
🔹 Три закона, стоят за саботажем :
- Закон неопределённости — любое решение можно подвергнуть сомнению из-за неполноты информации.
- Закон инерции — организация стремится к сохранению текущих процессов, любые изменения можно замедлить.
- Закон множественности интерпретаций — одна и та же проблема допускает множество решений, ни одно не является единственно верным.
🔹 Три принципа:
- Принцип «разделяй и властвуй» — распределяйте ответственность так, чтобы никто не видел общей картины.
- Принцип избыточности — создавайте больше этапов согласования, чем необходимо.
- Принцип ретроспективы — всегда ссылайтесь на предыдущий опыт или прецеденты, даже если они устарели.
🔹 Три правила:
- Правило «трёх вопросов» — перед любым решением задавайте три дополнительных вопроса, требующих нового анализа.
- Правило «бумажного следа» — любое важное решение должно быть оформлено письменно, но с множеством оговорок.
- Правило «последнего слова» — никогда не принимайте окончательное решение, оставляйте возможность пересмотра.
Как использовать в организации для блокировки решений других?
Если решение коллеги затрагивает ваши интересы, вы можете применить следующие тактики (всё в рамках «случайных» ошибок):
- Затягивайте согласование — требуйте дополнительные подписи, экспертизы, справки. Ссылайтесь на регламенты.
- Переопределяйте термины — утверждайте, что ключевые понятия в его предложении нечёткие, предложите альтернативные определения.
- Предлагайте контр-альтернативу — создайте своё решение, более сложное и ресурсоёмкое, чтобы его проект выглядел хуже.
- Используйте «провокационный вопрос» — спросите: «А учли ли вы влияние на отдел Х?», даже если это неважно. Это заставит его тратить время на дополнительные обоснования.
- Назначайте пилотные проекты — предложите сначала протестировать его решение в малом масштабе, но затяните тестирование.
- Ссылайтесь на внешние риски — укажите на возможные изменения законодательства или рынка, которые могут обесценить его идею.
- Собирайте «комитет по оценке» — включите туда несговорчивых людей, которые будут голосовать против или требовать доработок.
- Используйте бюрократию — требуйте письменное обоснование каждого пункта, а затем найдите формальные ошибки в оформлении.
- Затягивайте внедрение — если решение принято, предложите сложный план внедрения с поэтапными проверками, чтобы отодвинуть результат.
Главное — действовать не напрямую, а через процедуры и коллегиальные обсуждения, чтобы ваше противодействие выглядело как забота о качестве этого самого решения!
Вот примеры, выбирайте тот, который подойдет вам. Все примеры — из офисной или управленческой практики, где ошибка выглядит как досадное стечение обстоятельств.
1. Сбор избыточной информации
Кейс: Отдел маркетинга готовит запуск продукта. Руководитель вместо утверждения плана требует дополнительный анализ конкурентов за последние 5 лет, исследование потребительских настроений в 10 регионах и опрос фокус-групп. Сбор данных занимает 3 недели. За это время окно выхода на рынок закрывается, продукт устаревает. На совещании он говорит: «Мы хотели учесть всё, чтобы не ошибиться, но, к сожалению, время подвело». Его не наказывают — он же хотел как лучше.
2. Игнорирование ключевых данных
Кейс: Финансовый директор утверждает бюджет на основе отчёта прошлого квартала, не учтя свежие данные о падении спроса. Он берёт старые цифры, потому что «они были под рукой». В итоге завышенный план производства ведёт к затовариванию складов. На разборе он пожимает плечами: «Я использовал официальный отчёт, который был в системе, никто не предупредил, что он устарел». Формально он прав — данные были легитимны.
3. Создание ложных приоритетов
Кейс: Технический директор перенаправляет всех программистов на срочное исправление косметического бага в старом модуле, который почти не влияет на работу. Стратегическая задача — интеграция с новым API — откладывается. Через месяц заказчик уходит к конкуренту. На вопрос «почему» ответ: «Мы оценили баг как критичный, потому что он портил интерфейс для 0,5% пользователей, мы не думали, что это неважно». Выглядит как ошибка в оценке.
4. Двусмысленная формулировка целей
Кейс: Руководитель даёт задание: «Улучшить клиентский сервис». Менеджер внедряет бесплатные консультации по телефону, но не уточняет часы работы. Клиенты звонят в ночное время, никто не отвечает, рейтинг падает. На разборе руководитель говорит: «Я имел в виду скорость ответа, а не расширение часов». Ответственный возражает: «Вы сказали "улучшить" — я так и понял». Оба правы, но решение провалено, и вина расплывается.
5. Смена критериев успеха
Кейс: Проект по снижению затрат стартует с целью экономии 10%. Через месяц руководитель вводит новый критерий — «сохранение качества», которое измеряется субъективно. Команда перестраивает работу, тратит время на новые метрики. В итоге экономия — всего 3%, но качество чуть выросло. На отчёте он заявляет: «Рыночная ситуация изменилась, пришлось пересмотреть приоритеты». Его решение выглядит как адаптация, а не ошибка.
6. Голосование без кворума
Кейс: В совете директоров решение о покупке стартапа принимается на совещании, где присутствуют только 3 из 7 членов. Однако эти трое составляют большинство присутствующих и голосуют «за». Через месяц выясняется, что стартап убыточен. Отсутствующие возмущаются, но протокол подписан — голосование было правомочным, так как кворум не был оговорён в уставе. Организатор говорит: «Мы не знали, что остальные не придут, мы действовали в рамках регламента».
7. Разделение ответственности
Кейс: Запуск нового сайта поручают трём отделам: дизайн, разработка и контент. Каждый отвечает за свой блок, но никто не контролирует целостность. Дизайнеры сделали макет, разработчики сверстали, контент-менеджеры заполнили текстами — но на разных этапах перепутали версии. В итоге сайт выходит с битыми ссылками. На совещании все указывают друг на друга: «Я сделал свою часть». Генеральный не может наказать никого конкретно.
8. Использование внешних консультантов
Кейс: Компания нанимает дорогое агентство для выбора CRM-системы. Консультанты рекомендуют продукт, который не интегрируется с текущим софтом. Внедрение срывается, потери — миллионы. Директор говорит: «Мы доверились профессионалам, их заключение было обоснованным». Агентство ссылается на то, что компания не предоставила полные данные о своих системах. Обе стороны невиновны, решение оказалось ошибочным из-за «неполноты вводных».
9. Назначение на исполнение слабого сотрудника
Кейс: На ответственный переговорный проект ставят стажёра, потому что «все опытные заняты». Стажёр забывает согласовать ключевые пункты контракта, и сделка срывается. Руководитель отдела объясняет: «Он был единственным свободным, я не знал, что он не справится, он сам сказал, что всё понимает». В итоге выговор получает стажёр, а руководитель отдела отделается лёгким замечанием — он же не мог предвидеть некомпетентность.
Вопрос:
Как можно было предотвратить подобные ошибки?
ИП
19.06.2026