Очень знакомая картина. Компания купила ERP или собрала красивые формы в Excel, финансовая служба разослала их по подразделениям, а дальше начинается старая добрая корпоративная классика: кто-то молчит, кто-то пишет «мы это не считаем», кто-то честно спрашивает, что именно от него хотят, а кто-то смотрит на форму так, будто она пришла не на согласование, а с намёком на будущие проблемы.
И в этот момент обычно ставят простой диагноз: подразделения не хотят планировать.
Хотя в реальности проблема чаще совсем не в этом.
Подразделения нередко сопротивляются не самому планированию. Они сопротивляются плохо собранному процессу, в котором от них ждут ручного дубля, непонятной ответственности и цифр без ясного управленческого смысла.
Это встречается и в 1С:ERP, и в Excel. Разница только в технике. В Excel ручной труд видно сразу. В ERP он часто маскируется под «у нас же система», хотя по факту люди всё равно руками дособирают то, что уже можно было бы получить автоматически.
Поэтому главный вопрос здесь не в том, почему подразделения не дают планы. Главный вопрос другой: что именно компания просит у них делать руками, где рождаются исходные допущения, что должна считать система, а что действительно должен подтвердить руководитель функции.
И вот тут начинается самое интересное.
Почему подразделения не вводят планы
Первая ошибка компании в том, что она ищет одну причину. На практике причин обычно сразу несколько.
Первая причина очень простая: подразделение не понимает, зачем это ему.
Пользу планирования хорошо видят CFO, ФЭО, собственник, иногда генеральный директор. Но руководитель функции часто воспринимает всё иначе. Для него это ещё одна задача сверху, ещё один срок и ещё одна форма, связь которой с реальными управленческими решениями ему никто толком не объяснил.
Если человек не видит, как его участие влияет на закупки, загрузку, деньги, лимиты, приоритеты или KPI, планирование остаётся чужим процессом. Формально он в нём участвует, по смыслу — нет.
Вторая причина: план потом ни на что реально не влияет.
Если после сдачи форм решения всё равно принимаются в обход бюджета, лимиты с планом не связаны, план-факт почти не разбирается, а прогнозы живут отдельной жизнью, подразделения быстро понимают, что участвуют в ритуале. Все немного страдают, собирают файлы, а потом реальная жизнь идёт своим путём.
Третья причина: планирование не встроено в регулярный цикл управления.
Если оно существует как разовая акция «срочно пришлите цифры», оно и воспринимается как временный всплеск бюрократии. Рабочая логика выглядит иначе: план, факт, прогноз, корректировка, решение. Если этой цепочки нет, форма становится не инструментом управления, а сезонным мероприятием.
Четвёртая причина: подразделения не доверяют исходным данным.
Если факт спорный, аналитики неполные, нормативы устарели, цифры между системами не бьются, а плановая себестоимость в прошлом периоде уже удивила всех не в лучшем смысле, руководители не хотят подписываться под новым планом на такой базе. Их логика понятна: если фундамент шатается, почему я должен уверенно строить на нём второй этаж.
Пятая причина: люди не понимают методику.
Для одной функции план — это пожелание. Для другой — обязательство. Для третьей — укрупнённый ориентир. Для четвёртой — почти KPI. То же самое происходит со словами «прогноз», «корректировка», «лимит», «обязательство». Пока компания не проговорила единые правила, каждая функция участвует в процессе по-своему. А потом все удивляются, почему цифры есть, а договорённости нет.
Шестая причина: людей заставляют вручную дублировать то, что уже можно взять из системы.
И вот это одна из самых болезненных историй.
Если в системе уже есть история, нормативы, статьи, номенклатура, остатки, маршруты, графики, справочники или хотя бы база для расчёта, а подразделению всё равно присылают пустую форму и просят заново вбить руками то же самое, возникает вполне здравый вопрос: мы сейчас планируем или просто переписываем систему в другой файл?
И честно говоря, это очень хороший вопрос.
Седьмая причина: формы перегружены.
Иногда сама логика вроде правильная, но форма настолько тяжёлая, что в ней тонет весь смысл. Слишком много строк, аналитик, разрезов, вкладок и уточнений. В итоге вместо разговора о будущем получается тяжёлая работа по обслуживанию шаблона. Если основное решение человека в процессе — где он сейчас ошибся в строке 247, это уже не очень похоже на управление.
Восьмая причина: формы написаны на языке финансов, а не на языке функций.
Продажи думают объёмом, миксом, каналами, клиентами, сезонностью и ценой. Закупки — сроками, поставщиками, партиями, ценами и рисками дефицита. Логистика — пропускной способностью, маршрутами, пиками и ресурсами. HR — численностью, наймом, текучестью и фондами времени. Казначейство — лимитами, календарём платежей, приоритетами и кассовыми разрывами.
Если всем дать одну универсальную форму на языке финансовой службы, сопротивление будет естественным. Не потому, что люди плохие, а потому, что с ними говорят не на их управленческом языке.
Девятая причина: не разведены роли.
Очень часто в компании не определено, кто даёт исходные допущения, кто физически вводит данные, кто считает зависимые показатели, кто подтверждает итог, кто согласует спорные места, а кто консолидирует и принимает окончательное решение. Пока это не разведено, любая форма превращается в территорию взаимных ожиданий и мягких претензий.
Десятая причина: календарь бюджетной кампании нереалистичен.
От подразделений хотят качественный план, но дают на это полтора дня в тот момент, когда у них идёт обычная операционная работа. Потом задержка трактуется как саботаж, хотя иногда это просто физическая невозможность собрать материал качественно и вдумчиво.
Одиннадцатая причина: люди боятся, что план станет инструментом наказания.
Об этом редко говорят прямо, но причина очень живая. Руководитель функции думает так: если я сейчас дам цифру, через три месяца именно этой цифрой мне будут объяснять, почему я недоработал. И если при этом у него нет права оговорить риски, ограничения и условия исполнения, осторожность становится вполне рациональным поведением.
Двенадцатая причина: ответственность есть, а полномочий нет.
На показатель можно красиво назначить владельца, но если реально на него влияют другие функции, внешние ограничения или решения руководства, бумажная ответственность мало помогает. Подразделения очень остро чувствуют такие вещи.
Тринадцатая причина: нет права спорить с навязанным планом.
Если цифра спускается сверху, а от функции ждут только подтверждения, осмысленное участие быстро исчезает. Планирование без права на профессиональное возражение очень быстро превращается в формальность.
Четырнадцатая причина: нет права на комментарий и корректировку.
Во многих компаниях от функции ждут только саму цифру. Но цифра без комментария — слабый управленческий объект. Подразделение должно иметь право объяснить, почему это нереально, где ограничение, какие условия надо изменить, какой риск оно видит и что нужно для исполнимости плана.
Когда этого права нет, в форме остаются только числа, а вся реальная управленческая логика выносится за скобки.
ERP и Excel не решают проблему сами по себе
Здесь важно не впадать в крайности.
ERP не является волшебной кнопкой, после которой в компании автоматически появляется зрелое планирование.
Excel не является автоматически признаком хаоса, хотя при плохой постановке процесса вполне способен поддерживать его годами.
Суть проблемы и там и там одна: нельзя заставлять функции вручную пересобирать то, что уже можно было бы собрать из системы, и нельзя ждать качественного плана без понятной зоны ответственности и общей методики.
Если планирование идёт в ERP, часть базы уже действительно может жить в системе. Это плюс. Но если не разведены роли, не настроены источники, не определено, что считается автоматически, а что вводится вручную, ERP превращается в дорогую форму для ручного труда.
Если планирование живёт в Excel, ручной работы больше. Но и здесь не нужно делать вид, что каждая функция обязана вручную собирать весь свой бюджет целиком. Excel — это не оправдание для отсутствия архитектуры процесса.
Инструмент меняет технику. Он не заменяет методологию, роли, календарь и здравый смысл.
Кто тогда должен вводить исходные планы
Вот здесь чаще всего и возникает путаница.
Не все подразделения должны только подтверждать. И не все должны сами вручную собирать весь план. Правильная логика такая: исходные планы должны вводиться там, где рождаются первичные управленческие допущения. Всё, что может быть рассчитано на их основе автоматически или централизованно, не должно заново вручную собираться всеми функциями.
Продажи обычно вводят первичные коммерческие драйверы: объём, микс, сезонность, ключевые сделки, ценовые допущения, особенности каналов и клиентские риски. А дальше уже подтверждают реалистичность коммерческого плана и корректность этих допущений.
Закупки вводят свои драйверы: сроки поставок, ценовые ожидания, ограничения по поставщикам, особенности партий, риски дефицита и нестабильности. Подтверждают они уже исполнимость снабжения и реалистичность обеспечивающей части плана.
Производство вводит изменившиеся производственные драйверы там, где они не поддерживаются автоматически: ограничения по мощностям, специальные условия, изменённые нормы, брак, особенности цикла, узкие места. И подтверждает исполнимость производственного плана и те ограничения, которых система сама не знает.
Логистика и склад вводят допущения по пропускной способности, ресурсам, срокам, инфраструктурным ограничениям, сезонным пикам и прочим логистическим факторам. Подтверждают — реалистичность прохождения плана через свою цепочку.
HR вводит планы по найму, изменения численности, ограничения по подбору, кадровые условия, фонд рабочего времени и другие кадровые драйверы. Подтверждает реалистичность кадрового обеспечения.
Казначейство и финансы вводят лимиты, графики платежей, финансовые ограничения, параметры финансирования, кассовые риски и правила денежного контура. Подтверждают кассовую реализуемость модели.
Сервис, маркетинг, ИТ, административные функции тоже не должны выпадать из процесса только потому, что их вклад не всегда измеряется штуками продукции. Они вводят свои драйверы затрат, объёмы активности, ключевые изменения периода, ресурсные ограничения и крупные допущения. И подтверждают реалистичность своей части плана.
То есть подразделение не обязано вручную собирать весь бюджет. Его задача — вводить свои первичные драйверы там, где эти данные рождаются у него, и подтверждать итоговые планы там, где система или модель уже собрала проект автоматически.
Что должна считать система, а что должна подтверждать функция
Система, модель или финансовая служба должны делать то, что можно централизовать, стандартизировать и пересчитывать без участия каждой функции в каждой ячейке.
Это историческая база, шаблоны расчёта, зависимые показатели, связи между планами, подгрузка нормативной части, пересчёт итогов, консолидация, сценарии и контроль логических противоречий.
Функция должна делать другое.
Она должна вводить живые допущения, которые рождаются у неё. Подтверждать ограничения, которых система сама не знает. Давать комментарий по рискам, исполнимости и изменениям периода. Корректировать проект плана, если автоматически собранная конструкция не соответствует реальности.
То есть функция должна вручную подтверждать не то, что система уже знает, а то, чего система без неё знать не может.
Именно в этом месте у многих компаний и возникает путаница. Функцию начинают использовать как ручной интерфейс. А потом удивляются, почему люди не горят желанием участвовать.
О чём это, если говорить совсем просто
Представьте ремонт кухни. У вас уже есть замер помещения, план розеток, размеры техники и схема коммуникаций. И вот на этом фоне вам говорят: а теперь нарисуйте всё это ещё раз от руки, иначе мы не сможем понять, куда поставить шкаф.
Нарисовать, конечно, можно. Но вопрос будет не в ваших художественных способностях, а в том, почему процесс устроен так, будто предыдущих данных не существует.
С планированием та же логика.
Если данные уже живут в системе или хотя бы в расчётной модели, нельзя строить процесс так, будто их нет и всё должно быть заново переписано вручную.
Ручной ввод оправдан только там, где появляется новый управленческий смысл: новое допущение, новый риск, новое ограничение, новый комментарий по исполнимости.
Что делать с понедельника
Здесь не нужен проект на полгода, чтобы хотя бы начать двигаться в правильную сторону. Очень многое можно понять за одно рабочее совещание.
Сначала разберите текущую форму и разделите все её поля на три группы:
- что уже есть в системе;
- что считается автоматически;
- что действительно должно вводиться или подтверждаться руками.
Потом по каждому ключевому показателю разведите роли:
- кто даёт исходные допущения;
- кто физически вводит данные;
- кто считает зависимую часть;
- кто подтверждает результат;
- кто согласует спорные места.
После этого посмотрите на форму глазами функции. Не глазами ФЭО, а глазами продаж, закупок, логистики, HR, сервиса. Видит ли человек в ней свой управленческий язык? Понимает ли он, что именно здесь его зона ответственности? Или перед ним просто универсальная финансовая матрица?
Следующий шаг — сократить лишнюю детализацию. В форме должно остаться только то, что реально влияет на решения. Всё, что создаёт объём работы, но не создаёт нового качества управления, лучше убрать или укрупнить.
Отдельно важно дать подразделениям право на комментарий. Не только цифру, но и пояснение: почему это нереально, где ограничение, какие условия надо изменить, что функция считает критическим риском.
И ещё одна важная вещь: подразделение должно иметь право вернуть неисполняемый план на пересборку. Не в смысле «мы ничего не хотим делать», а в смысле профессионального сигнала: при текущих условиях план не собирается, нужны изменения в допущениях, сроках, объёме или ресурсах.
И, конечно, планирование нужно встроить в регулярный цикл. Если нет план-факта, прогноза, корректировки и решений по отклонениям, даже хорошо собранная форма останется разовой кампанией.
Что сказать руководителю и коллегам
Руководителю это можно объяснить очень просто.
Проблема не в том, что подразделения не хотят планировать. Проблема в том, что мы не развели, что система должна считать сама, что функция должна вводить как первичный драйвер и что руководитель функции должен подтвердить как свою зону ответственности. Пока этого разведения нет, мы будем получать тяжёлый ручной процесс, низкое доверие к цифрам и формальную вовлечённость.
Коллегам по функциям можно говорить ещё проще.
Продажам — от вас нужен не файл ради файла, а реальные коммерческие допущения.
Закупкам — нужны сроки, цены, риски и исполнимость снабжения.
Производству — ограничения, изменившиеся нормы и честная оценка исполнимости, а не роль ручного калькулятора.
HR — кадровые ограничения и планы по людям.
Финансам — не только консолидация, но и нормальная архитектура процесса.
На совещании это можно сформулировать совсем коротко: давайте не искать виноватых среди людей. Давайте разделим показатели на четыре группы:
- где рождается исходное допущение;
- кто его вводит;
- что считает система;
- кто подтверждает итог.
После этого половина споров обычно становится намного короче.
Финал
Подразделения не всегда отказываются планировать. Чаще они отказываются участвовать в плохо собранной модели, где от них ждут не управленческого решения, а ручного дубля и ответственности без ясных полномочий.
Поэтому хороший процесс планирования начинается не с формы и не с покупки системы. Он начинается с более приземлённых вещей: общей методики, доверия к данным, разведения ролей, понятного календаря и права функции не только дать цифру, но и объяснить её.
ERP может очень помочь. Excel тоже может быть рабочим переходным контуром. Но ни один инструмент сам по себе не решает вопрос: кто рождает исходные допущения, кто что считает и кто за какие цифры отвечает.
Когда это разведено, подразделения начинают не просто отправлять формы, а реально участвовать в управлении.
А когда это не разведено, даже очень хорошая система быстро скатывается в жанр «мы же вроде это уже где-то заполняли».