• Оглавление
  • Зачем это бизнесу
  • ABC и TDABC простыми словами
  • Из каких блоков состоит решение
  • План внедрения на 6–10 недель
  • Быстрые победы и где искать эффект
  • Драйверы затрат: что собирать и как не перегнуть
  • Типовые ошибки и как их избежать
  • Метрики успеха и отчёты
  • Как выбрать инструмент и не утонуть в интеграциях
  • Роли и ответственность: кто за что отвечает
  • Кейс: «невидимая» маржа в дистрибуции
  • Качество и безопасность данных
  • FAQ: частые вопросы руководителей

Зачем это бизнесу

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

• маржа «средняя по больнице»;
• дорогие клиенты выглядят выгодными, потому что носят крупные обороты;
• дешёвые товары тянут на себе склад, логистику и сервис, оставаясь «в плюсе» только на бумаге;
• каждый квартал — новый раунд споров между продажами и финансами.

Автоматизация калькулирования по ABC/TDABC позволяет прозрачно связать косвенные расходы с конкретными действиями: заказ, доставка, возврат, консультация, поддержка ИТ и т. д. Мы получаем маржу в разрезе продукта, клиента, канала, региона, партии. И главное — не раз в квартал, а по регулярному циклу: раз в неделю или месяц, без ночных марафонов в Excel.

Бизнес-эффект:

• +2–6 п.п. к валовой марже за счёт корректной цены и отказа от убыточных хвостов;
• −30–70% времени на расчёты и сверки;
• меньше конфликтов между функциями: цифры становятся общими и прозрачными;
• уверенность в переговорах с ключевыми клиентами и поставщиками.

ABC и TDABC простыми словами

• ABC (калькулирование на основе видов деятельности): мы выделяем виды работ (например, «обработка заказа», «подготовка отгрузки», «поддержка клиента»), собираем затраты по каждому виду и распределяем их на продукты/клиентов по понятным драйверам: количество заказов, строк, звонков, квадратные метры, километры и т. п.
• TDABC (калькулирование, ориентированное на время): то же самое, но ключевой драйвер — время. Сколько минут реально уходит на операцию, сколько стоит минута ресурса, как меняется загрузка. Метод проще в поддержке: обновляешь нормы времени — и модель остаётся актуальной.

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

Из каких блоков состоит решение

1) Данные

• заказы и строки заказов;
• отгрузки, доставки, возвраты;
• работы склада и логистики;
• обращения в поддержку/колл‑центр;
• производственные операции (если есть);
• справочники: продукты, клиенты, каналы, регионы;
• бухгалтерские и управленческие статьи затрат.

2) Драйверы затрат

• количество заказов, строк, накладных;
• количество доставок, километры, паллетоместа, кубы;
• минуты на обработку запроса, на комплектование, на инвентаризацию;
• количество инцидентов ИТ, пользователей, лицензий;
• площади (м²) для аренды и коммуналки.

3) Модель распределения

• пулы затрат по функциям: продажи, логистика, склад, ИТ, финансы, HR;
• правила: «затрата X идёт в пул Y», «пул Y разносится по драйверу Z»;
• вторичные распределения (например, ИТ → все функции по числу пользователей).

4) Отчётность и контроль

• маржа по продукту/клиенту/каналу с детализацией «из чего сложилась»;
• сравнение периодов, сценарии «что если» (цена, MOQ, частота доставки);
• карта чувствительности: какие драйверы влияют сильнее всего.

План внедрения на 6–10 недель

Неделя 1–2: Диагностика и границы

• Фиксируем цели: pricing? ассортимент? каналы? сервис?
• Выбираем зоны: например, B2B‑дистрибуция и e‑commerce отдельно.
• Собираем текущие отчёты, определяем недостающие данные.

Неделя 3–4: Первая версия модели

• Фиксируем список пулов затрат и драйверов (10–20 ключевых, не больше на старте);
• Описываем нормы времени для TDABC (короткие тайм‑замеры, экспертные оценки);
• Строим первую «сквозную» связку: затраты → пулы → драйверы → объекты калькуляции.

Неделя 5–6: Пилот и сверки

• Прогон за 1–2 месяца, проверка на здравый смысл;
• Разбор «аномалий»: куда «улетают» миллионы, где двойной учёт;
• Совместный разбор с продажами и операциями — добиваемся принятия модели.

Неделя 7–8: Автоматизация загрузки и обновления

• Настраиваем регулярную загрузку данных из учётных систем и CRM/склада;
• Формируем витрины для отчётов, настраиваем дашборды;
• Обучаем владельцев данных обновлять нормы времени/драйверы.

Неделя 9–10: Эксплуатация и сценарии

• Переходим на регулярный цикл (неделя/месяц);
• Добавляем «что если»: новая цена, изменение частоты доставки, MOQ;
• Закрепляем регламент: кто и когда обновляет что.

Быстрые победы и где искать эффект

• Минимальный заказ (MOQ): посчитайте себестоимость линии заказа. Часто 20–30% заказов в «минус» из‑за мелких партий.
• Частота доставок: редкие крупные отгрузки почти всегда выгоднее ежедневных мелких.
• Возвраты и обмены: отдельный драйвер, который «съедает» маржу по ряду клиентов.
• Сервисные соглашения (SLA): обслуживание «платиновых» клиентов должно быть заложено в цену.
• Ассортиментный «хвост»: 10–20% SKU генерируют диспропорциональные расходы на поддержку.

Драйверы затрат: что собирать и как не перегнуть

Принцип: лучше 15 надёжных драйверов, чем 60 «на глаз». Примеры по функциям.

Продажи

• количество встреч/звонков/предложений;
• количество клиентов в портфеле на 1 менеджера;
• количество согласований по тендерам.

Склад и логистика

• строки в заказе, паллетоместа, кубы, килограммы;
• расстояние/зоны доставки, количество точек в маршруте;
• количество операций: приемка, комплектация, упаковка, возврат.

Клиентский сервис

• обращения по каналам (телефон, чат, почта);
• среднее время обработки по типам вопросов;
• доля повторных обращений.

ИТ и офис

• число пользователей, лицензий, инцидентов;
• метры офисов, рабочие места;
• принтеры/серверы, их обслуживание.

Совет: на старте избегайте драйверов, которые тяжело собрать регулярно. Лучше приблизительный, но стабильный показатель, чем «идеальный», но раз в полгода.

Типовые ошибки и как их избежать

1. Делать «большой взрыв». Начинайте с одной бизнес‑линии.
2. Собирать слишком детально. Модель должна обновляться за часы, а не за недели.
3. Путать управленческий и бухгалтерский учёт. Здесь важна причинно‑следственная связь, а не нормативы бухгалтерии.
4. Непрозрачные правила распределения. Любое правило должно объясняться в одну минуту.
5. Игнорировать вторичные распределения (ИТ, HR). Без них функции «недооценены».
6. Нет владелцев драйверов. Должен быть конкретный человек за каждый источник.
7. Не проверять на здравый смысл. Сверяйтесь с «землёй» — реальными процессами.
8. «Закатывать в бетон». Модель должна жить и меняться раз в квартал.
9. Не учитывать сезонность. Драйверы и нормы времени меняются по сезонам.
10. Доверять только средним. Смотрите на хвосты: именно там убытки.

Метрики успеха и отчёты

• Доля ассортимента/клиентов с отрицательной маржей (после косвенных) — цель: ↓
• Время расчёта очередного периода — цель: часы, а не недели;
• Доля косвенных расходов, распределённых по драйверам (не «по выручке») — цель: >80%;
• Принятые решения: изменённые цены, закрытые SKU, пересмотренные SLA — считаем и фиксируем эффект;
• Точность: расхождение между суммой распределённых затрат и фактом — <1%.

Ключевые отчёты:

• Маржа по продукту/клиенту/каналу с «разборкой» косвенных по функциям;
• Карта прибыльности клиентов (матрица «выручка/маржа после косвенных»);
• Аналитика заказов: влияние размеров партии и частоты доставки;
• Драйверная панель: как меняются ключевые драйверы и нормы времени.

Как выбрать инструмент и не утонуть в интеграциях

Здесь не требуется «тяжёлый» ERP‑проект. Подойдут современные платформы для моделирования затрат или даже BI с аккуратной моделью, если объём умеренный.

Критерии выбора:

• прозрачная настройка пулов и правил, версионирование модели;
• удобный расчёт TDABC (нормы времени, ставки ресурсов);
• сценарии «что если» и сравнение периодов;
• контроль качества данных: полнота, дубликаты, сверка с фактом;
• интеграция с вашими источниками и выгрузка в BI для визуализации;
• управляемые роли и права доступа.

На старте допустим полуавтоматический цикл: регулярные выгрузки из системы и загрузка в модель. Главное — ритм и прозрачность. Когда подтвердите ценность, добавите «кнопку обновить» по расписанию.

Роли и ответственность: кто за что отвечает

• Спонсор (обычно финдиректор): цель, границы, принятие решений.
• Владелец модели (FP&A/контроллинг): методология, регламент, изменения.
• Владелцы драйверов (операции, логистика, продажи, ИТ): качество данных.
• Аналитик/разработчик: сбор данных, настройка расчёта, отчёты.
• Менеджеры направлений: используют отчёты и обязаны принимать решения.

Регламент: ежемесячное обновление модели, квартальный пересмотр драйверов и норм времени, отдельный цикл по проверке «хвостов» (убыточные клиенты/SKU).

Кейс: «невидимая» маржа в дистрибуции

Компания‑дистрибьютор электроники. На уровне валовой прибыли всё «красиво»: 14–16%. Но склад, логистика и сервис «размазывались» пропорционально выручке.

Что сделали за 8 недель:

• Завели пулы затрат: склад, доставка, возвраты, претензии, ИТ, финансы;
• Ввели драйверы: строки заказа, паллетоместа, километры, минуты на обработку возврата;
• Посчитали TDABC для ключевых операций склада и клиентского сервиса;
• Запустили ежемесячный расчёт и дашборды в BI.

Выводы:

• 22% заказов оказались убыточными из‑за мелких партий и частых доставок;
• 11 SKU приносили 40% претензий и «съедали» маржу по двум клиентам;
• «Платиновому» клиенту SLA включал бесплатные срочные доставки — после пересмотра условий маржа выросла на 3,2 п.п.

Решения и эффект за 3 месяца:

• ввели MOQ и плату за срочную доставку — +1,8 п.п. маржи;
• закрыли 60 «хвостовых» SKU — высвободили 12% складского времени;
• пересмотрели SLA двум клиентам — плюс 24 млн руб. годового эффекта.

Качество и безопасность данных

• «Один источник правды» по справочникам: продукты, клиенты, каналы. Ошибки в кодах = ошибки в марже.
• Логирование расчётов: кто, когда, какую версию модели запускал.
• Проверки на полноту: все ли затраты распределены, нет ли «висяков».
• Права доступа: финансы видят всё, коммерция — свой контур, персональные данные — по минимуму.
• Документация правил: каждое правило распределения описано в одну страницу и одобрено владельцем функции.

FAQ: частые вопросы руководителей

Это заменит бухгалтерский учёт?

Нет. Это управленческая модель для принятия решений. С бухгалтерией сверяемся на уровне сумм, но логика — причинно‑следственная, а не нормативно‑правовая.

Сколько драйверов нужно?

На старте 10–20 ключевых. Потом добавляйте только те, что влияют на решения. Лишняя детализация — враг регулярности.

Как часто пересматривать нормы времени?

Раз в квартал или при изменении процессов/сезона. Короткие замеры + здравый смысл + обратная связь от операционщиков.

Можно ли без дорогостоящих систем?

Да. Начните с аккуратной модели в удобном инструменте и BI‑дашбордов. Когда эффект подтверждён — расширяйте автоматизацию.

Что делать с «политикой» между функциями?

Делайте модель прозрачной, с понятными правилами и совместной валидацией. Итоговые решения по ценам и SLA — ответственность бизнеса, а не «чёрного ящика».

---

Итог: автоматизация ABC/TDABC — это не про «идеальную математику», а про регулярную, понятную и принятую всеми модель расходов. Она даёт честную маржу по продуктам и клиентам, ускоряет решения и убирает споры. Начните с одной линии бизнеса, 15 драйверов и прозрачных правил — и уже через 6–10 недель вы увидите, где действительно зарабатываете, а где — субсидируете чужие ошибки.