Все при деле. Результат подождёт? | Дмитрий Махин

26 октября 2026г. 9 минут чтения.



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

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

На вопрос собственника «Когда получим эффект?» есть обстоятельный ответ на двадцать слайдов. Даты в нём пока нет: ожидания акционеров и менеджмента существенно отличаются.

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

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

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

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

На первом совещании все согласны. Кто же будет против сокращения сроков и высвобождения оборотного капитала?

Дальше начинаются подробности.

Производство готово менять график, если поставки станут предсказуемыми. Закупки готовы обеспечить поставки, если заранее получат окончательную потребность. Коммерческая служба объясняет, что потребность зависит от клиентов, а клиенты почему-то продолжают корректировать заказы.

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

Через месяц рабочая группа приходит к важному выводу: проблема комплексная.

Создаётся расширенная рабочая группа.

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

• Финансы — бюджет и денежный поток.
• Закупки — условия поставки.
• Производство — выпуск.
• Логистика — доступность транспорта и стоимость доставки.

Все эти задачи необходимо решать. Проблема возникает, когда их начинают решать по отдельности.

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

В отчётах разных подразделений одна и та же ситуация может выглядеть совершенно по-разному. Где-то появилась экономия. Где-то выросла эффективность. А общая маржа заказа уменьшилась.

На совещании каждый способен объяснить свои действия. В компании от этого объяснения денег не прибавляется.

У решения обычно есть автор. Есть дата, подпись и вполне конкретный человек, которому потом зададут вопросы.

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

Каждый отдельный запрос может быть оправдан. Вместе они способны сделать проект бессмысленным.

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

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

Самая сложная для руководителя ситуация — когда инициативу формально продолжают поддерживать, постепенно убирая условия её успеха.

➡️ Новую систему внедряем, но процессы пока не меняем.

➡️ Обслуживание ускоряем, но численность и полномочия оставляем прежними.

➡️ Точность планирования повышаем, но порядок предоставления исходных данных и их источники не пересматриваем.

Каждая такая уступка облегчает согласование. После нескольких уступок полезно заново посчитать экономику.

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

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

Что показал мой опыт внедрения 1С:ТОиР

В одном из холдингов, где я работал, управление ремонтами было разрозненным: локальные базы, Excel, бумажные журналы. При внедрении 1С:ТОиР для работы с заявками, планирования ремонтов и учёта запчастей потребовалось решать вопросы общих справочников, обмена данными и интеграции с 1С:ERP.

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

Коэффициент технической готовности — Ктг — на десяти производственных линиях достиг 0,99. Оборудование эксплуатировалось в жёстком режиме 24/7, без резерва и с минимальным запасом запчастей.

Но единого контура управления ремонтами для всего холдинга не появилось: на остальных предприятиях сохранились прежние системы и подходы.

Работоспособность решения на пилоте и готовность компании распространить его — два разных вопроса. Для масштабирования требовались отдельные решения о ресурсах, общих правилах и изменении работы подразделений. Успех пилота их не заменил.

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

В моей практике изменения требовали настойчивости. Но одной силы воли и дипломатии недостаточно. Руководитель не может бесконечно заменять собой порядок взаимодействия подразделений.

Я бы выделил пять вещей, которые стоит проверять ещё на старте.

💡 1. Общий результат и условия его получения

Участники должны договориться, какой показатель бизнеса меняется и за счёт чего. Если рассчитываем сократить срок заказа, нужно назвать конкретные изменения в планировании, обеспечении материалами и запуске производства. Тогда при сокращении проекта будет видно, что можно отложить, а без чего обещанный эффект уже недостижим.

💡 2. Реальные полномочия владельца

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

💡 3. Цена ожидания

Вместе с рисками запуска следует обсуждать последствия отсрочки. Какие потери продолжатся? Что изменится на рынке? Сколько времени останется на получение эффекта?

💡 4. Проверка смысла после изменений

Сократили бюджет, перенесли срок, исключили часть работ — пересчитайте результат. Первоначальное обоснование не может бессрочно оправдывать любую последующую версию проекта.

💡 5. Ответственность за взаимодействие

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

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

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

🎯 Три вопроса на ближайшее совещание:

➡️ Какой результат даст проект в его нынешнем, уже согласованном виде?

➡️ Какого конкретного решения или ресурса сейчас не хватает для его получения?

➡️ Кто вправе устранить это ограничение и к какой дате?

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