О карго‑культе аналитики, невидимых потерях и важном вопросе, который стоит задать до старта

1. Когда процесс есть, а смысла нет

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

Руководитель, который требует времени на анализ, выглядит тормозом.

Руководитель, который объявляет изменение — выглядит лидером.

Система последовательно вознаграждает второго.

И в этой логике «повышенной оперативности» аналитический этап становиться одновременно и жертвой (вынужденной) некомпетентности, и результатом вполне рациональной калькуляции: анализ дорого стоит сейчас, а его отсутствие дорого обходится потом, но «потом» — не в этом квартале.

Именно поэтому следующая история не об исключении.

Ситуация

Крупная компания инициирует замену корпоративного BI‑решения на отечественный аналог. 150+ аналитиков, 1K+ активных пользователей в день и 1K+ отчётов. Даже формально проект выглядит специфически, но (для корпоративных проектников) в пределах нормы: около года команда потратила на требования, анализ рынка и скоринг решений. В этих процессах участвовали все, в том числе те, о ком так часто забывают — от ИБ до Архитектурного штаба. Все решения прошли утверждение командой и были приняты на нескольких управленческих уровнях.

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

Когда новая система встала (новое решение не выдержало нагрузки, старое деградировало из‑за перераспределения железа, основная команда внедрения (она же команда линейного развития), потеряла четырех сотрудников, функция BI оказалась плачевном положении), а интеграторы пожали плечами и исчезли (договор и ТЗ позволяли), заказчик признал правоту «паникеров». Проект перезапустили, позиции заказчика деградировали к его «базовым» настройкам.

Здесь важно зафиксировать суть: все укатилось в на рестарт не по причине отсутствия анализа или (даже) времени на анализ — формально он проводился на высоком уровне, с участием всех нужных людей и внутренних институтов. Она показывает, что карго‑культ анализа опаснее его отсутствия (и что управление масштабными проектами IT‑внедрения за 200M+ лучше доверять профильным специалистам). Он потребляет ресурсы, создаёт «алиби» для согласователей и блокирует экспертный здравый смысл тех, кто видит проблему, называет её вслух, но не может остановить машину, уже получившую формальную санкцию двигаться вперёд.

2. Имитация дороже отсутствия

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

Проблема в том, что имитация анализа, как и его отсутствие, дают весьма схожий результат. Даже годы работы, тысячи страниц документации, штабы и комитеты в полном составе могут быть идеально организованным ритуалом, за которым нет ни одного содержательного решения. При этом именно наличие этого ритуала делает провал защищённым (и когда система встаёт, разбор полётов превращается в соревнование по точности формулировок в протоколах).

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

За этим стоит более неудобный тезис, который методологические руководства предпочитают обходить стороной: полноценный анализ (то есть не аудит ради документа, а реальное прояснение «откуда», «зачем», «как», «куда» и «с какими последствиями для смежных систем/процессов») возможен только при одном условии: лица, принимающие решения, должны быть готовы а) потратить на это ресурсы, б) услышать ответы, которые им могут не понравятся и в) действовать исходя из реальных вводных.

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

3. Невидимый счётчик

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

Суть в том, что вне зависимости от природы и масштабов, каждое непроработанное изменение оставляет после себя долг — не только технический, хотя и его тоже, но и:

  • Архитектурный долг: интеграции (и сейчас не столько по IT), которые держатся на договорённостях между конкретными людьми, а не на системной логике.

  • Процессный долг: сбои и «костыли» (особенно в кросс‑функциональных связях), которые становятся новой нормой.

  • Организационный долг: неформальные компенсаторные практики, которые закрывают разрывы, но не учитываются в системе.

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

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

И здесь ответ на вопрос, который в подобных разговорах задают редко:

Почему опытные руководители воспроизводят этот паттерн даже после собственного негативного опыта?

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

4. Рациональный человек в иррациональной системе (и наоборот)

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

Руководитель, который запускает непроработанное изменение, не обязательно жертва собственных когнитивных ошибок. Он часто действует абсолютно рационально — четко в рамках системы, которая его окружает. Давление на результат исходит сверху. Горизонт ответственности за последствия — короче, чем горизонт проявления этих последствий. Коллеги, которые действуют быстро, получают видимые очки. Те, кто требует времени, получают репутацию людей, усложняющих простые вещи. В такой системе координат пропуск реального аналитического этапа — это обычная адаптация.

Но есть слой, который рациональным объяснением не закрывается. Кейс с BI показывает его отчётливо: заказчик располагал экспертными заключениями, предупреждениями, прямыми указаниями на конкретные технические и технологические риски, но последовательно двигался в противоположную сторону.

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

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

5. Ответ

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

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