ABC (Activity-Based Costing) — это калькуляция по видам деятельности, где косвенные расходы привязываются не к “выручке” и не к “цехам”, а к операциям (обработка заказа, переналадка, контроль качества, перемещения, комплектация, претензии).
В практике ABC становится спасательным кругом, когда доля косвенных затрат высокая, ассортимент разросся, а маржа вдруг начала “плавать” без понятной причины.
Ключевые слова, которые будем “приземлять”: пулы затрат, драйверы, ставки драйверов, емкость ресурсов, стоимость обслуживания заказа, маржинальность по продукту/клиенту.
Внутри — границы модели, выбор подхода (включая TDABC), типовые ошибки и план, который можно реально сделать за 60–90 минут без героизма.
Вызов: Управленческий вопрос на повестке
Когда косвенные расходы распределяются “по выручке” или “по объёму”, маржинальность становится мнением, а не управленческим фактом.
Главный вопрос: где именно процесс съедает деньги — в операциях, очередях, срочности или усложнении сервиса?
И два обязательных: что делать с понедельника? и как донести до руководства?
Система координат: Глоссарий и основа методологии
ABC-калькуляция — метод, где затраты идут по цепочке: ресурсы → виды деятельности (операции) → объекты затрат (продукт, заказ, клиент, канал).
Пул затрат — группа расходов, которые логично “кормить” одним драйвером (например, “комплектация заказов”, “контроль качества”, “внутренняя логистика”).
Драйвер затрат — измеритель объёма операции, который объясняет изменение затрат (строки заказа, переналадки, проверки, паллето-перемещения, часы настройки).
Ставка драйвера — стоимость единицы операции (руб./переналадка, руб./строка, руб./проверка).
Простыми словами. Мы перестаём спорить “накладные выросли”, и начинаем видеть: выросло количество операций, усложнились маршруты, добавилась срочность и контроль. Мы управляем не “накладными”, а причинами их возникновения.
Пример: не “склад дорогой”, а “много мелких заказов → много строк отбора → много перемещений → склад перегружен”.
Что включаем в модель
● Операции, которые повторяются и считаются (заказы, строки, перемещения, переналадки), потому что без измерения нет управляемости.
● Косвенные расходы, которые “размазываются” и искажают маржу, потому что именно они чаще всего создают конфликты “план-факт” и “продажи vs производство”.
● Операции, где появляется срочность/очереди, потому что там рождаются сверхурочные, простои, дорогие закупки и “пожары”.
● Участки с высоким качественным риском (переделы, ОТК, рекламации), потому что там легко перепутать “экономию” с будущими потерями.
Что НЕ включаем в модель
● Разовые редкие расходы, потому что они добавляют шум и ломают причинно-следственную логику.
● Детализацию “всё про всё”, потому что стоимость администрирования модели может стать выше эффекта.
● Драйверы “потому что так проще выгрузить”, потому что это возвращает распределение в режим “на глаз”.
Единица анализа — заказ/партия/клиент/продуктовая группа (выбираем там, где реально принимаются решения по цене, сервису, ассортименту).
Пример: если спор из-за скидок и бонусов — единица анализа “клиент/канал” и показатель “стоимость обслуживания заказа”.
Период — чаще всего месяц для финансовой дисциплины + недельный мониторинг драйверов для управляемости (чтобы не ждать закрытия периода).
Требуемая точность — в пределах управленческого решения, а не “до копейки”: для старта достаточно 80/20, если модель помогает менять правила (партии, маршруты, приоритеты, стандарты сервиса).
Цель расчётов: Ответы на ключевые управленческие вопросы
● Почему маржинальность продукта “в отчёте” хорошая, а по факту деньги исчезают в операциях после продажи?
● Какие клиенты/каналы дают выручку, но создают сверхзатраты через срочность, мелкие партии, возвраты и сложную комплектацию?
● Какие операции являются реальными драйверами роста косвенных расходов: переналадки, контроль качества, внутренняя логистика, обработка заказов?
● Где дешевле “прибить причину”: менять правила сервиса, укрупнять партии, ограничивать срочность или пересматривать ассортимент?
● Какие нормативы по операциям должны быть “нормой” при текущем объёме бизнеса (и где мы живём в исключениях)?
Методология: Различные подходы к решению одной задачи
Подход 1. Классический ABC (пулы → драйверы → ставки)
Цель — точно объяснить распределение косвенных расходов по продуктам/клиентам через операции.
Что считаем — пулы затрат по видам деятельности и ставки драйверов (руб./строка, руб./переналадка, руб./проверка).
Где ломается — когда драйверы выбирают “по доступности данных”, а не по причинности, и модель превращается в красивую имитацию точности.
Пример: распределить склад “по весу отгрузок” — удобно, но не отражает строки заказа, пики, адресное хранение и дробление партий.
Подход 2. TDABC (Time-Driven ABC: через время и ёмкость ресурсов)
Цель — сделать ABC масштабируемым и живым, когда операций много, а ручная детализация дорогая.
Что считаем — стоимость минуты/часа ресурса (по ёмкости) и время на операцию (time equations), затем получаем стоимость операций и объектов затрат.
Где ломается — когда “время на операцию” берут из головы и не обновляют при изменениях процесса (новые правила комплектации, упаковки, контроля).
Пример: время сборки заказа зависит от количества строк, хрупкости, типа упаковки и срочности — это и есть “уравнение времени”.
Подход 3. ABC-light (управленческий 80/20 для быстрых решений)
Цель — быстро выделить топ-операции, которые создают 70–80% косвенных затрат, и принять решения по правилам.
Что считаем — 5–7 пулов, 5–7 драйверов, минимальная аналитика по объектам затрат (продуктовые группы/каналы).
Где ломается — когда пытаются выжать из “лайта” точность тарифов и начинают требовать детализацию как в диссертации.
Пример: “стоимость обслуживания заказа” по каналам и типам клиентов — уже достаточно, чтобы пересмотреть минимальные партии и сроки.
Подход 4. ABC как надстройка к стандарт-костингу (норматив + операции)
Цель — разделить себестоимость на нормативную часть (материалы/труд) и операционную часть (сервис, переналадки, внутренние перемещения, качество).
Что считаем — прямые затраты по нормам + косвенные через операции (ABC/TDABC).
Где ломается — когда отклонения “прячут” в общих статьях и не связывают с драйверами (срочность, переделки, очереди).
Сравнение подходов
● Если нужна объяснимость и “разложить по полочкам” — чаще подходит классический ABC.
● Если операций много и модель должна жить без ручного героизма — лучше смотреть в сторону TDABC.
● Если задача — быстро найти, где съедается маржа, и поменять правила — рационально начать с ABC-light.
● Если у вас уже сильный нормативный контур и болит косвенная часть — хорошо работает гибрид стандарт-костинг + ABC.
Типовые ошибки: На что обращать внимание
Ошибка: Выбирают драйвер “потому что он есть в выгрузке”, а не потому что он объясняет расход.
Риск: Модель становится недоверяемой, а решения — спорными, потому что причинность не подтверждается.
Как проверить за 2 минуты: Возьмите один пул затрат и спросите: “Если драйвер вырастет на 20%, затраты почти точно вырастут?” Если нет — драйвер неверный.
Ошибка: Делают слишком много пулов и аналитик “на старте”, пытаясь сразу покрыть 100% расходов.
Риск: Закрытие периода превращается в ручной ад, модель бросают, а команда ненавидит слово “ABC”.
Как проверить за 2 минуты: Посчитайте количество драйверов. Если их больше 10–12 на первом запуске — вы, скорее всего, строите музей, а не инструмент управления.
Ошибка: Не фиксируют правила “исключений” (срочность, нестандартная упаковка, спецконтроль) и потом удивляются скачкам себестоимости.
Риск: Исключения становятся нормой, и стоимость операций расползается.
Как проверить за 2 минуты: Посмотрите долю заказов “с особыми условиями”. Если она растёт — это не “везение”, это поломка правил.
Ошибка: В TDABC не считают ёмкость и загрузку ресурсов, а “стоимость часа” берут как среднюю.
Риск: Вы теряете главное преимущество TDABC — понимание, где перегруз и где простаивание.
Как проверить за 2 минуты: Есть ли у вас понятие “доступные часы” и “фактическая загрузка” по ключевым участкам? Если нет — это не TDABC, это фантазия про время.
Ошибка: Используют ABC как инструмент “обвинений” (кто виноват), а не как инструмент “правил процесса” (что менять).
Риск: Сопротивление, саботаж данных и вечные споры на совещаниях.
Как проверить за 2 минуты: Вопрос на совещании звучит как “почему вы…?” вместо “какое правило процесса меняем?” — значит, вы идёте в конфликт, а не в управление.
Что делать с понедельника: План на 60–90 минут
Входные данные (подготовить заранее): оборотно-сальдовая/управленческие расходы по статьям, список операций процесса, выгрузка объёмов (заказы, строки, переналадки, проверки), перечень объектов затрат (продуктовые группы/клиенты/каналы).
Шаг 1. 10 минут. Зафиксируйте цель: для чего ABC (ценообразование, ассортимент, правила сервиса, выявление “дорогих” клиентов).
Шаг 2. 15 минут. Выберите 1 процесс для пилота (например, “заказ → отгрузка” или “производство → контроль → склад”). Опишите 5–7 операций.
Шаг 3. 15 минут. Соберите 5–7 пулов затрат под эти операции (только те статьи, которые реально “живут” в процессе).
Шаг 4. 15 минут. Назначьте драйвер на каждую операцию и проверьте причинность: драйвер должен объяснять рост/падение затрат.
Шаг 5. 10 минут. Посчитайте ставки драйверов (пул / объём драйвера) и сделайте первый прогон по объектам затрат (группы продуктов/клиенты/каналы).
Шаг 6. 10 минут. Найдите 2–3 “сюрприза” (где стоимость обслуживания резко выше ожидаемой) и сформулируйте управленческие гипотезы: партия, срочность, упаковка, возвраты, контроль.
Шаг 7. 10 минут. Согласуйте 3 правила процесса, которые меняете: минимальная партия/слоты, запрет “срочности без причины”, стандарты комплектации/контроля.
Итог плана:
Что видим: где у объекта затрат стоимость операций непропорциональна выручке/объёму.
Почему: какой драйвер разогнал операции (строки, переналадки, проверки, перемещения, срочность).
Что делаем: какое правило процесса меняем (условия сервиса, партии, приоритеты, стандарты, ограничения).
Как объяснить руководителю и коллегам: Скрипты
Руководителю: версия на 60 секунд
Мы не усложняем учет и не “пересчитываем себестоимость ради спорта”. Мы хотим увидеть, какие операции съедают маржу: обработка мелких заказов, срочность, переналадки, контроль качества, внутренняя логистика. ABC покажет стоимость операций и стоимость обслуживания заказа/клиента. Дальше мы меняем правила процесса: минимальные партии, правила срочности, стандарты комплектации и контроля. Итог — меньше пожаров, выше предсказуемость и более честная маржинальность для решений по цене и ассортименту.
Коллегам по ролям
Продажи: вам станет проще защищать цену и условия — мы покажем, какие типы заказов реально дорогие в обработке.
Производство: это не про “кто виноват”, это про переналадки, очереди и правила партий — где мы теряем время и деньги.
Логистика/склад: увидим, что разгоняет операции: строки, пики, адресное хранение, упаковка, возвраты — и какие стандарты дают эффект.
Закупки: станет видно, где срочность и дробление партий вызывают дорогие поставки и лишние перемещения.
Бухгалтерия/учет: регламентированный учет не ломаем — добавляем управленческую логику распределения по драйверам, чтобы цифры были воспроизводимыми.
Микро-пример “что сказать на совещании”: “Мы не спорим о сумме накладных. Мы смотрим, какие операции выросли и почему: строки заказа, переналадки, проверки, перемещения. Дальше решаем, какое правило меняем, чтобы операций стало меньше.”
Наглядно: О чём это, если говорить просто?
Мини-кейс на цифрах. Было: пул “обработка заказов” 6 млн и пул “складская комплектация” 9 млн, распределяли “по выручке”, и всё выглядело терпимо. Посчитали по драйверам: строки заказа и паллето-перемещения. Оказалось, что канал с небольшой выручкой съедает 35% операций из-за мелких заказов и срочности. Ввели правило минимальной партии и слоты отгрузок. Через 2–3 месяца: обработка заказов −1,5 млн, комплектация −2 млн, жалобы на “вечную срочность” тоже неожиданно снизились.
Жизненный сюжет: кухня. Вы можете покупать продукты “на неделю” и готовить спокойно — или ежедневно забегать в магазин “за одной мелочью”, каждый раз теряя время, нервы и деньги на “случайные покупки”. По сумме чеков иногда даже не видно, что вы переплачиваете — но по количеству походов видно сразу.
Перевод на язык темы: срочные мелкие заказы — это “походы за одной мелочью”. Каждая такая мелочь создаёт операции: строки, перемещения, комплектацию, контроль, документы, очереди.
Управленческий вывод: оптимизация начинается не с “урезать накладные”, а с правил, которые уменьшают количество операций: партии, графики, стандарты, ограничения срочности и прозрачные условия сервиса.
Финал
● ABC углублённо нужно не для красивых отчётов, а чтобы связать рубль с операцией и управлять причинами затрат.
● Начинайте с границ и цели, иначе получите модель, которая “всё считает”, но ничего не решает.
● Драйвер — это причинность, а не “удобный показатель из выгрузки”.
● TDABC полезен, когда операций много и нужна масштабируемость через ёмкость и время.
● Лучший эффект даёт не расчёт, а изменение правил процесса: партии, срочность, стандарты, приоритеты.
Вопрос: какая операция у вас больше всего разгоняет косвенные расходы — мелкие заказы, переналадки, контроль качества, внутренняя логистика или возвраты?
Если хотите — дам шаблон пилота ABC/TDABC на 5–7 драйверах и список “нормальных” драйверов для производства/склада/продаж, чтобы не утонуть в НСИ.
И да: когда “накладные” наконец превращаются в операции, у многих резко портится настроение — особенно у тех, кто любил слово “объективно”.