Три правила, которые не дают компании потерять реальность

Лозунг - "говорите правду" не работает.

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

Первое. Красный статус не перекрашивается в зелёный.

Красный - это превышение измеримого порога: вехи, бюджет, допустимое отклонение (например +10%). Не мнение, не настроение. Если по факту проблема - она и в отчёте для акционера обозначена как проблема. Без переупаковки в зелёный.

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

Здесь важен предохранитель. Красный статус - это сигнал, не приговор. Если за красный автоматически режут бонусы, его начнут прятать через "подкрутку" показателей, на которых работает автоматика. Менять руководителя проекта при затянувшемся красном - последний шаг, не первый. Сначала RCA, эскалация на нужный уровень, фасилитация команды. Сигнал означает "нужен ресурс или решение", виноватого по нему не ищут.

Второе. Источник данных не подчиняется владельцу результата.

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

Это базовый принцип разделения ответственности: тот, кто реализует результат, не должен сам себя оценивать. Дело не в доверии к конкретному человеку. Система не должна строиться на личной честности и порядочности одного руководителя.

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

Третье. За плохие новости не наказывают. За их сокрытие - да.

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

Это не отменяет ответственности. Она просто смещается с поиска виноватого на разбор причины и системную правку. Иначе система не учится. Это не теория: исследования Эми Эдмондсон и Project Aristotle в Google показывают, что психологическая безопасность - один из ключевых факторов результативности команд [1].

В технологическом контуре это "blameless postmortem" и RCA. В финансах - внутренний аудит. В операциях - структурированные разборы. Реализация разная, граница одна: за принесённую плохую новость не наказывают, за сокрытую - наказывают всегда.

Внедрить эти правила достаточно тяжело. Каждое из них отнимает у конкретной управленческой роли конкретный инструмент власти. Сопротивление идёт от тех, кто привык работать "прокладкой" между правдой и бордом.

Сильнее всего обычно бьёт правило про независимый источник данных. Когда руководитель функции теряет монополию на интерпретацию своих показателей, он теряет возможность переупаковать их перед бордом. Это ровно те же действия, что перед Коте показали управленцы на первом совещании в Honeywell: продать бизнес ради разового дохода, перетянуть выручку из будущего, сменить метод учёта. Когда источник данных независим, такая упаковка становится намного сложнее.

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

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

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

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

Но чтобы проводить эти правила как защиту, самому нужен мандат от борда. Мандат - это не декларация, что "ИТ важно". Это архитектура прав на решения, "decision rights", без которой все три правила превращаются в пожелания. По данным Gartner (опрос 2024 года) цифровые инициативы достигают целей в 63% случаев, когда CIO работает во франшизной модели - держит общую рамку, а инициативы ведут функции, - и в 43%, когда остаётся оператором внутри своей функции [2]. Разрыв в 20 процентных пунктов - не разрыв в компетенциях, это разрыв в правах на решения.

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

• не согласовывать отчётность, в которой статус по факту не соответствует реальным цифрам;
• останавливать инициативы, у которых нет независимого источника проверки результата;
• требовать единых формул там, где разные функции считают одно и то же по-разному.

Без мандата CIO продаёт эти правила руководителям функций в одиночку, и его переговорная сила зависит от личного веса в компании. С мандатом - за ним стоит CEO или акционер, и у сопротивления появляется верхний потолок. Если этих трёх правил нет, всё остальное в управлении ИТ - декорация.

Основной вывод

Компании убивают не конкуренты и не технологии - они начинают умирать, когда решения принимаются на основе красиво упакованной версии реальности.

Линейные сотрудники знают, что происходит, но наверх уходит безопасная версия: по статусу, бюджету, репутации, квартальному результату. Дальше компания управляет тем, что успели красиво упаковать.

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

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

Для этого у CIO должно быть две опоры:

• говорить на борде то, что показывают данные, даже если эти данные портят чью-то красивую версию.
• влиять на архитектуру управленческой реальности: единые формулы, единые определения, независимые источники проверки, согласованный поток данных между CIO, CDO и CFO.

Без первого CIO исполняет чужие решения, даже когда видит, что они построены на иллюзии. Без второго CIO, CDO и CFO могут работать с разными версиями одной и той же реальности. Каждый видит свою картину, а компания теряет общий контур управления. Именно поэтому три правила из этой статьи не работают как лозунги. Они работают только как часть управленческой конструкции:

• красный статус не перекрашивается в зелёный,
• источник данных не подчиняется владельцу результата,
• за плохие новости не наказывают, за их сокрытие - да.

Последний вопрос я оставляю без ответа:

Если завтра вы предложите эти три правила в компании - найдутся ли на борде хотя бы двое, кто встанет рядом с вами в открытую?

Источники

• [1] Amy Edmondson, психологическая безопасность; Google, Project Aristotle, 2016
• [2] Gartner, опрос CIO 2024: franchise model против operator model