Управление затратами через процессы — это подход, при котором затраты связываются с конкретными операциями, а не «размазываются» по подразделениям или статьям “для отчетности”.
Он нужен, когда доля косвенных затрат растёт, ассортимент расширяется, а маржинальность “плывет” при одинаковой выручке.
Типовая боль: деньги уходят “в накладные”, а ответ на вопрос “почему именно так” превращается в презентацию на 30 слайдов.
В статье разберём: какие границы модели выбрать, какие вопросы она должна закрывать, какие методологии применимы и с чего начать за 60–90 минут.
Вызов: Управленческий вопрос на повестке
Когда компания управляет затратами только через бюджеты и лимиты, она часто контролирует сумму, но теряет причину.
Вопрос на повестке: как связать расходы с процессами так, чтобы видеть драйверы, а не только отклонения?
И два практических вопроса: что делать с понедельника? и как донести до руководства?
Система координат: Глоссарий и основа методологии
Процесс — повторяемая последовательность операций, которая превращает входы (материалы, время, услуги) в результат (продукт, отгрузку, сервис).
Процессные затраты — затраты, привязанные к операциям процесса (настройка, контроль, перемещение, обработка заказа), с понятным измерителем объёма работы.
Драйвер затрат — показатель объёма операции, который объясняет, почему затрат стало больше или меньше (заказы, переналадки, проверки, километры, паллето-места).
Пул затрат — группа однородных расходов, которые логично распределять одним драйвером (например, «контроль качества», «внутренняя логистика»).
Простыми словами. Мы перестаём спорить “почему накладные выросли” и начинаем видеть: выросло число операций, усложнился маршрут, изменилась партия, добавились проверки.
Пример: не “склад подорожал”, а “выросло количество перемещений и сборок из-за дробления заказов на мелкие партии”.
Система координат: Границы модели
Что включаем в модель
● Операции, которые повторяются и дают измеримый объём (заказ, перемещение, переналадка), потому что без измерения нет управления.
● Косвенные затраты, которые «переезжают» между продуктами и клиентами, потому что именно они чаще всего искажают маржинальность.
● Узкие места процесса (участки/этапы, где копятся очереди), потому что там рождаются сверхурочные, простои и срочные закупки.
● Обязательные контуры качества/комплаенса, потому что их “оптимизация” без контроля быстро превращается в потери другого типа.
Что НЕ включаем в модель
● Редкие разовые расходы, потому что они дают шум и мешают увидеть закономерности.
● Детализацию «до винтика» по всем операциям, потому что стоимость администрирования модели может превысить пользу.
● Спорные распределения без драйверов, потому что это сразу возвращает модель в режим “верим/не верим”.
Единица анализа. Обычно это заказ/партия/изделие/клиентский сегмент — выбираем то, где принимаются решения по цене, ассортименту и сервису.
Пример: если основной конфликт в скидках и бонусах, единицей анализа становится клиент/сегмент и “стоимость обслуживания заказа”.
Период. Для управления процессами чаще всего работает месяц (стабильность данных) плюс недельный мониторинг драйверов (оперативность).
Пример: себестоимость закрываем месяцем, а количество переналадок и срочных поставок смотрим еженедельно, чтобы не ждать закрытия периода.
Цель расчётов: Ответы на ключевые управленческие вопросы
Цель — получить ответы, которые меняют решения, а не просто “уточняют отчётность”.
● Где именно в процессе мы теряем маржу: в логистике, в переналадках, в контроле качества, в обработке мелких заказов?
● Какие продукты/клиенты “дорогие в обслуживании”, даже если по выручке они выглядят хорошо?
● Какие изменения дадут эффект: укрупнение партий, пересмотр маршрутов, правила приоритизации, стандарты качества, ограничения по срочности?
● Что считать нормой: какой уровень операций должен быть при текущем объёме бизнеса?
Методология: Различные подходы к решению одной задачи
1) ABC (калькуляция по видам деятельности)
Подходит, когда косвенные затраты велики и важно понять, какие активности “едят” ресурсы.
Пример: распределяем затраты складской обработки по драйверу “строки отбора”, а не по выручке.
2) Process costing (попроцессный учет)
Подходит, когда производство/оказание услуг поточное, а важна стоимость этапа и выходов этапа.
Пример: стоимость подготовки сырья, затем стоимость обработки, затем упаковки — и видно, где рост.
3) Value Stream Costing (затраты по потокам создания ценности)
Подходит, когда компания управляет потоками/линиями, а не отдельными изделиями, и хочет связывать затраты с потоком “от заказа до отгрузки”.
Пример: отдельный поток “стандартные изделия” vs “кастом”, и разные правила срочности/контроля.
4) Standard costing + анализ отклонений
Подходит, когда есть нормы и важно управлять отклонениями по причинам: цена, расход, производительность, простои.
Пример: видим отклонение не “в рублях”, а “из-за переналадок + из-за брака + из-за срочных закупок”.
5) TOC (теория ограничений) как фильтр для управленческих действий
Подходит, когда главная проблема — узкое место и очереди; тогда “экономия” вне узкого места не даёт эффекта.
Пример: оптимизация участка, который не ограничение, снижает себестоимость “на бумаге”, но не повышает выпуск и не улучшает сроки.
Типовые ошибки: На что обращать внимание
Ошибка 1. Модель строят “как бухгалтерию”, а использовать хотят “как управление”: итог — красивый отчёт без решений.
Ошибка 2. Драйверы выбирают по удобству выгрузки, а не по причинно-следственной связи: распределение получается случайным.
Ошибка 3. Пытаются сразу детализировать всё: команда тонет в НСИ и перестаёт закрывать период.
Ошибка 4. Не фиксируют правила, где заканчивается “процесс”, и начинается “исключение”: срочность становится нормой.
Ошибка 5. Не договариваются о целях: один ждёт “точность для тарификации”, другой — “направление для решений”, и спор бесконечен.
Что делать с понедельника: План на 60–90 минут
Цель сессии — выбрать 1–2 процесса и сделать первую управляемую версию модели.
● Выберите процесс, который чаще всего вызывает споры: “заказ-отгрузка”, “планирование-производство”, “закупка-поставка”.
● Выпишите 5–7 операций процесса и 1 измеритель на операцию (драйвер).
● Сопоставьте каждой операции один пул затрат (какие расходы туда попадают).
● Определите, где нужна точность, а где достаточно порядка величин (это снижает трудоёмкость).
● Согласуйте 3 правила: что считать исключением, как маркировать срочность, как закрывать период без ручных правок “задним числом”.
Пример: “срочный заказ” — только при флаге и причине, иначе это обычный заказ и живёт в общей очереди.
Как объяснить руководителю и коллегам: Скрипты
Скрипт для руководителя. “Мы не усложняем учет. Мы делаем модель, которая показывает, какие операции создают затраты, и где изменения дадут маржу. Отчёт нужен не ради точности до рубля, а ради управляемости.”
Скрипт для производства/логистики. “Мы не оцениваем людей. Мы измеряем объём операций: переналадки, перемещения, проверки. Если драйвер вырос — значит процесс изменился, и это повод обсуждать правила, а не искать виноватых.”
Скрипт для коммерции. “Цена и условия должны учитывать стоимость обслуживания заказа. Мы покажем, какие типы заказов требуют больше операций, и договоримся о правилах срочности и минимальных партиях.”
Скрипт для бухгалтерии/учета. “Модель не ломает регламентированный учет. Она добавляет управленческие разрезы и правила распределения, чтобы цифры закрытия периода были воспроизводимыми.”
Наглядно: О чём это, если говорить просто?
Это как перейти от вопроса “почему выросли расходы на транспорт” к вопросу “почему выросло число рейсов и почему мы возим воздух”.
Это как перестать делить накладные “по выручке”, и начать видеть, что один продукт требует 2 операции, а другой — 12.
Это как сделать так, чтобы спор “у нас дорогая себестоимость” превращался в список решений: партия, маршрут, контроль качества, правила срочности.
Финал
Главная мысль: процессный подход делает затраты управляемыми, потому что связывает рубль с действием и драйвером.
● Сначала выбирайте границы и единицу анализа, потом детализацию.
● Драйвер без причинно-следственной связи — это не драйвер, а способ “распределить красиво”.
● Лучшая модель — та, которую можно закрывать каждый месяц одинаково.
Вопрос (чтобы собрать кейсы): какой процесс у вас вызывает самые жёсткие споры — “производство”, “склад/логистика” или “коммерция/сервис”?
И да: когда затраты наконец привязаны к процессу, спорить становится скучно. Обычно это хороший знак.