Типовой сценарий: автоматизация план-факт сверки на пищевом производстве

Обезличенный типовой сценарий. Ниже — методика: как строится такой контур и что в нём замеряется. Профиль компании и цифры условны: это разобранный сценарий, а не конкретный клиент и не обязательство результата. Величину эффекта считаем на пилоте на ваших данных.

Профиль: пищевое производство (FMCG), 3 площадки, 200+ SKU. Ежедневная план-факт сверка идёт в Excel и съедает около 4 часов ручной работы: выгрузки из 1С, сопоставление с планом, поиск отклонений, формирование отчёта для руководства. Автоматический контур на Python оставляет человеку только проверку готового отчёта — 15–20 минут. Насколько это изменится у вас — считаем на пилоте на ваших данных.

Задача: как устроена ручная сверка

Ручной процесс на четыре часа в день, который сам производит ошибки.

Ручной сбор данных

Плановик каждое утро выгружает данные из 1С по трём площадкам, копирует в единый Excel-файл, сопоставляет с плановыми значениями. На сбор и подготовку уходит 2–2,5 часа.

Ручная сверка и анализ

После сбора — ручное сравнение: что выпущено, что отклонилось от плана, по каким позициям и линиям. Поиск причин отклонений, комментарии по каждой позиции. Ещё 1–1,5 часа.

Ошибки и задержки

Ошибки копирования: не та ячейка, устаревшая версия плана, пропущенные строки. Отчёт для руководства опаздывает на 1–2 часа. На время отпуска плановика сверка не делается вообще.

Подход: от пилота к промышленному контуру

Три этапа: пилот на одной площадке, масштабирование, мониторинг.

Этап 1. Пилот: одна площадка, один отчёт (3 недели)

Python-скрипт забирает данные из 1С через API, сопоставляет с планом (Excel-файл), рассчитывает отклонения по каждой позиции и линии, генерирует готовый Excel-отчёт с подсветкой критических отклонений. Запуск по расписанию в 7:00.

Этап 2. Масштабирование: все площадки (4 недели)

Подключаем оставшиеся площадки: адаптация конфигурации под разные структуры данных в 1С, единый отчёт с разбивкой по площадкам. Добавляем валидации: проверка полноты данных, алерт при расхождениях > 10%.

Этап 3. Мониторинг и сопровождение

Логирование каждого запуска, алерты в Telegram при сбоях, панель мониторинга с историей отклонений для руководства. Передача документации и регламента сопровождения внутренней команде.

Что меняется (величину считаем на пилоте)

Ниже — что именно меняется. Величину не называем заранее: её считаем на пилоте на ваших данных по цепочке базовая линия → изменение → показатели.

День плановика освобождается

Вместо 4 часов ручной работы — 15–20 минут на проверку автоматического отчёта. Освободившееся время плановика уходит на анализ причин отклонений и работу с участками.

Ошибки ручного ввода исчезают как класс

Автоматический сбор данных из 1С убирает ручное копирование как класс ошибок. Типичный переход — с 3–5% до менее 1% (оставшиеся — ошибки в исходных данных 1С).

Окупаемость: из чего складывается

Две статьи эффекта: высвобожденные часы плановика (часы × ставка) и снижение потерь от ошибок в отчётности. Горизонт окупаемости считается на ваших ставках и объёмах — цифра появляется после замера baseline, до старта разработки.

Технический стек подробнее

Выбор инструментов определяют три фактора: наличие API в 1С (через COM-объект и HTTP-сервисы), необходимость ежедневного автоматического запуска и требование к формату отчёта — Excel с формулами и условным форматированием, привычный для руководства.

Python + openpyxl + pandas

Основной стек — Python 3.11 с библиотеками pandas (трансформация и агрегация), openpyxl (генерация Excel с условным форматированием), requests (HTTP-запросы к 1С). Pandas даёт описать логику сверки декларативно: merge плановой и фактической таблиц по ключам (SKU + площадка + дата), расчёт отклонений через vectorized-операции. Полный цикл по трём площадкам укладывается в секунды-десятки секунд на таких объёмах.

Интеграция с 1С

На стороне 1С публикуется HTTP-сервис, возвращающий JSON с данными выпуска за указанную дату. Формат: массив записей с полями SKU, площадка, линия, план, факт, единица измерения. Аутентификация — базовая (логин/пароль сервисного пользователя). Если базы 1С по площадкам разные, каждой нужен свой endpoint. Унификация структур данных — самая трудоёмкая часть работы: типичный случай, когда на одной площадке SKU хранятся строками, а на другой — числовыми кодами.

Планировщик и алерты

Запуск по расписанию — через cron (Linux-сервер в контуре компании). Логирование — Python logging в файл + ротация. При ошибках (недоступность 1С, неполные данные, превышение порога расхождений) уходит сообщение в Telegram-канал через Bot API. Для руководства готовый Excel-файл выкладывается на сетевой диск и дублируется ссылкой в корпоративный мессенджер.

Что замеряем на пилоте: базовая линия → изменение → KPI

Три метрики, по которым виден эффект. Baseline фиксируется до разработки, замер после запуска идёт по тому же определению — иначе сравнение недоказуемо. Значения «после» — ожидаемые, а не наши замеры у клиента: их считаем на пилоте.

Время подготовки отчёта

Baseline: хронометраж дня плановика — 3,5–4,5 часа ежедневно (сбор данных — 2–2,5 ч, сверка — 1–1,5 ч, оформление — 30 мин). Ориентир после: 15–20 минут на проверку и комментирование автоматического отчёта, то есть порядка 70 высвобожденных часов в месяц — они уходят на анализ причин отклонений и работу с производственными участками. KPI: часы на подготовку отчёта за неделю и их доля в загрузке плановика.

Ошибки в данных

Baseline: доля записей с ошибками копирования — не та ячейка, устаревший план, дубли строк. Типично 3–5%: две-три ошибки в день, которые всплывают только на разборе с руководством. Ориентир после: менее 1%, и это уже ошибки в исходных данных 1С (непроведённые документы, задержки ввода). Автоматическая валидация ловит такие случаи и помечает их в отчёте жёлтым цветом. KPI: число расхождений, вызванных подготовкой отчёта, а не производством.

Покрытие и устойчивость

Baseline: сколько дней в месяце сверка не делается или опаздывает. Отпуск и болезнь плановика дают 1–3 дня подряд, совещания и выезды сдвигают отчёт на 1–2 часа. Ориентир после: отчёт формируется по расписанию каждый день, включая выходные для сменного производства; доступность конкретного человека перестаёт влиять на выпуск отчёта. KPI: доля дней с отчётом вовремя и время от алерта до восстановления. Типичный сбой — недоступность 1С на время обновления; целевое время восстановления задаётся регламентом сопровождения.

Совет. Фиксируйте метрики «до» ещё на этапе пилота — до начала разработки. После запуска сравнивать будет поздно: люди быстро забывают, «как было раньше», и эффект невозможно доказать без базовой линии.

Типичные ошибки при автоматизации план-факт сверки

Эти грабли повторяются почти на каждом контуре план-факт сверки. Что стоит учесть заранее.

Ошибка 1: автоматизировать «как есть»

Соблазн — просто перенести ручной процесс в код. Но ручной процесс часто содержит обходные пути и неявные правила, которые плановик держит в голове. Частый пример: на одной площадке плановик вручную исключает из сверки «технологические партии» (пробные запуски), а на другой — учитывает их. Без формализации этих правил автоматизация даёт некорректные цифры. Решение: перед разработкой провести 2–3 интервью с плановиком и зафиксировать все неявные правила.

Ошибка 2: игнорировать задержки проведения в 1С

Данные в 1С появляются не мгновенно: документы проводятся с задержкой (от 30 минут до конца смены). Если скрипт запускается в 7:00, а часть документов за вчерашний день ещё не проведена — отчёт покажет ложное отклонение. Решение: добавить «буфер ожидания» (запуск в 7:00, но данные берутся за позавчера) или quality gate, который проверяет полноту (сумма факта >= 90% от типичного дневного объёма).

Ошибка 3: не предусмотреть изменение плана

План производства — не статичный документ. Он корректируется 2–3 раза в неделю. Если скрипт берёт план из фиксированного Excel-файла, а плановик обновил его вчера вечером — сверка идёт по устаревшему плану. Решение: хранить план в 1С или в отдельной базе с версионированием, а не в Excel-файле на сетевом диске. Если 1С невозможна — минимально: автоматическая проверка даты модификации файла плана и алерт при несовпадении.

Совет. Заведите «журнал инцидентов» с первого дня работы автоматизации. Каждый ложный алерт, каждое расхождение с ожиданием — записывайте причину и решение. Через месяц у вас будет готовый FAQ для внутренней команды.

Уроки и рекомендации

Что советуем учесть на старте похожего проекта.

Начинайте с одной площадки

Пилот на одной площадке даёт быстро отладить логику, найти нестыковки в данных 1С и зафиксировать паттерны. Дальше площадки подключаются заметно быстрее: правила сверки уже описаны, меняется только источник.

Валидация данных — обязательна

В 1С данные не всегда полные: бывают пустые поля, задержки проведения документов. Quality gates (проверка полноты перед сверкой) снимают ложные алерты до того, как их увидит руководство.

Передавайте знания

Документация, регламент сопровождения и обучение внутренней команды — не «потом», а часть проекта. Без этого автоматизация становится новой зависимостью от подрядчика.