Добавить в корзинуПозвонить
Найти в Дзене

План vs Факт в 1С: ERP: Как подружить отчетность для заказчика с реальным производством

Вопрос от пользователя: «С заказчиком отчетность и расчет цены ведутся по "плановым", часто укрупненным видам работ, а внутри компании производство, учет затрат и оплата труда ведутся по "фактическим", детализированным операциям. Это делает прямое корректное сравнение "план/факт" невозможным и приводит к неконтролируемым отклонениям». Представьте, что вы руководите производством, которое выпускает уникальные штучные изделия под конкретный проект. В начале пути вы вместе с заказчиком согласовываете смету. Чтобы оценить стоимость, вы используете укрупненные плановые нормы: «Проектирование — 200 часов», «Сборка блока А — 150 часов». Заказчик эту смету утверждает. А потом начинается производство. Технологи разбивают «Сборку блока А» на 15 конкретных операций: «приготовить деталь Х», «настроить станок Y», «проверить параметр Z». Рабочие получают зарплату именно по этим реальным, детализированным нормам. В чем конфликт? Сравнивать их — все равно что сравнивать километры с метрами. В итоге вы
Оглавление

Вопрос от пользователя: «С заказчиком отчетность и расчет цены ведутся по "плановым", часто укрупненным видам работ, а внутри компании производство, учет затрат и оплата труда ведутся по "фактическим", детализированным операциям. Это делает прямое корректное сравнение "план/факт" невозможным и приводит к неконтролируемым отклонениям».

Суть проблемы

Представьте, что вы руководите производством, которое выпускает уникальные штучные изделия под конкретный проект. В начале пути вы вместе с заказчиком согласовываете смету. Чтобы оценить стоимость, вы используете укрупненные плановые нормы: «Проектирование — 200 часов», «Сборка блока А — 150 часов». Заказчик эту смету утверждает.

А потом начинается производство. Технологи разбивают «Сборку блока А» на 15 конкретных операций: «приготовить деталь Х», «настроить станок Y», «проверить параметр Z». Рабочие получают зарплату именно по этим реальным, детализированным нормам.

В чем конфликт?

  • Для заказчика вы отчитываетесь по старым, укрупненным цифрам.
  • Внутри компании живет другая, детальная цифровая реальность.

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

Функциональное назначение механизма

Механизм «Типовые технологические процессы (ТТП)» и «Вид цены» — это цифровой мост между двумя мирами: миром плановой отчетности для заказчика и миром оперативного учета для производства.

Его суть — создать стройную систему, где:

  1. План «привязан» к факту через общие технологические этапы.
  2. Фактические данные автоматически агрегируются в плановые статьи.
  3. База для распределения затрат является стабильной и понятной для всех сторон.

Как работает

Процесс строится на нескольких ключевых действиях.

1. Создание единого планового языка — Типовых технологических процессов (ТТП)

  • На этапе подготовки к проекту технологи и экономисты совместно создают библиотеку ТТП. Это не детальные инструкции, а укрупненные этапы: «Проектирование интерфейса», «Комплексные испытания».
  • Именно эти ТТП с их плановой трудоемкостью идут в коммерческое предложение для заказчика.

2. Формирование детальных маршрутов на основе ТТП

  • Когда проект запускается, технологи на базе ТТП разрабатывают детальную «Рабочую ресурсную спецификацию». Здесь этап «Комплексные испытания» расписывается на 10 конкретных операций.
  • Ключевой момент: каждая детальная операция в системе наследует принадлежность к своему «родительскому» ТТП. Это позволяет позже «свернуть» факт в план.

3. Ежемесячная фиксация базы распределения через «Вид цены»

  • Это центральный элемент для финансового учета. Создается специальный «Вид цены», например, «База распределения затрат по проекту».
  • Каждый месяц экономисты определяют, какая часть от общей плановой трудоемкости проекта должна быть признана в текущем месяце (например, мы планировали 1000 часов на весь проект, в этом месяце отрабатываем 100).
  • Рассчитанная плановая сумма заработной платы для этих 100 часов регистрируется в системе именно для этого «Вида цены».
  • Важно: эта сумма является нормативной, плановой. Она не зависит от того, переработали ли рабочие в этом месяце или сэкономили время. Это гарантирует стабильную и предсказуемую базу для распределения всех остальных затрат (материалы, амортизация) в рамках проекта.

4. Автоматическое сравнение «План/Факт»

  • Система автоматически агрегирует все фактические трудозатраты по детальным операциям и «сворачивает» их до уровня плановых ТТП.
  • Руководство получает отчет: «По проекту №Х: плановая трудоемкость этапа "Испытания" — 50 часов, фактическая — 70 часов. Отклонение +20 часов».
  • Это дает точку для анализа: были ли объективные сложности, занижена ли плановая норма или нужна оптимизация процесса.

Решение и рекомендации

  1. Начните с библиотеки ТТП. Формализуйте укрупненные плановые нормы, чтобы они перестали быть «прикидками на салфетке».
  2. Внедрите «Вид цены» для распределения затрат. Это методически чистое решение, которое обеспечит прозрачность финансов по каждому проекту.
  3. Настройте отчеты для анализа отклонений. Не просто констатируйте разницу, а делайте срез по привязке к ТТП, чтобы понимать, на каком именно этапе возникло отклонение.
  4. Разграничьте зоны ответственности. Экономисты работают с планом (ТТП и «Виды цен»), технологи — с детализацией (Рабочие спецификации). Это исключает хаос и двойную работу.

Итог простыми словами

Представьте, что вы строите уникальный дом по индивидуальному проекту.

Без системы:
Вы согласовали с заказчиком смету по статьям «Фундамент», «Стены», «Кровля». А потом прораб каждому строителю ставит задачи вроде «уложить 15 кирпичей», «замесить бетон марки М300». В конце месяца вы видите, что по смете «Стены» — 500 тыс. руб., а по факту выплатили зарплату и купили материалов на 700 тыс. Почему? Непонятно. То ли смета неверная, то ли были переделки, то ли материалы дороже.

С системой:
В смете те же «Фундамент», «Стены», «Кровля». Но у прораба есть технологическая карта, где статья «Стены» состоит из конкретных операций, каждая из которых привязана к этой сметной статье. Система автоматически собирает все затраты по этим операциям и показывает: «По статье "Стены" перерасход в 200 тыс. руб., из-за чего: 100 тыс. — дополнительные работы по усилению, 100 тыс. — рост цены на кирпич».

Это и есть управление себестоимостью. Вы не просто констатируете разницу, а понимаете ее причины и можете принимать взвешенные решения.