Павел Козлов, «Росатом Критические информационные технологии»: «Наличие отчёта на экране само по себе не обеспечивает управляемость»

Павел Козлов, директор по персоналу и организационному развитию, АО «Росатом Критические информационные технологии», и спикер Девятой конференции «Цифровизация промышленности», поделился с CFO Russia опытом, как сохранить эффективность управления производством в условиях цифровой трансформации.

Какие управленческие решения позволяют сохранить управляемость при внедрении цифровых технологий, и какое из них оказалось самым трудным на практике?

Я предлагаю начать с пяти решений. Первое: какой результат в работе мы хотим изменить и с чем будем его сравнивать. Например, сократить время согласования задания, сохранив требования к качеству и безопасности. Второе: кто отвечает за результат и что этот человек вправе менять. Третье: каким данным мы доверяем и кто разбирается с расхождениями. Четвёртое: что сотрудники начинают делать иначе и какие прежние действия прекращаются. Пятое: при каких условиях мы расширяем внедрение, дорабатываем решение или приостанавливаем переход.

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

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

Управляемость для меня означает, что руководитель видит отклонение, понимает его последствия и может принять необходимое решение. Наличие отчёта на экране само по себе этого не обеспечивает.

Как руководителю удержать баланс между результатом, ответственностью и полномочиями в условиях трансформации?

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

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

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

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

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

По каким критериям стоит масштабировать цифровые решения, чтобы они не разрушали управляемость производства?

Я бы проверял готовность к масштабированию по пяти признакам.

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

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

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

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

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

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

Задать свои вопросы Павлу и узнать больше об опыте АО «Росатом Критические информационные технологии» вы сможете на Девятой конференции «Цифровизация промышленности», которая состоится 13 ноября 2026 года.

Елизавета Гета