Кейсы

Как мы подключили живое производство к 1С:ERP без остановки фабрики и без переделки бизнес-процессов

2026-09-22 15:12 Внедрение 1С:ERP
Производство на фабрике мягких игрушек «Мякиши» устроено гибко: приоритеты перекраиваются по ходу дня, цеха переключаются между изделиями на лету, заготовки перемещаются между участками без формального документооборота. Типовые механизмы 1С:ERP рассчитаны на другую логику. Перестраивать работающее производство под программу мы не стали и нашли другой путь: источником данных стала сдельная оплата труда. Теперь фабрика видит картину производства каждый день, а не раз в две недели.
Эта статья — подробный разбор самого сложного блока в проекте внедрения ERP на фабрике «Мякиши». Обзорный кейс по всему внедрению — как мы перевели учёт фабрики из четырёх программ в одну систему.

С какой ситуацией мы столкнулись

«Мякиши» — российская фабрика мягких игрушек, около 15 производственных цехов, несколько сотен сотрудников. Когда в рамках внедрения ERP дело дошло до производственного блока, выяснилось, что процессы на фабрике устроены совсем иначе, чем заложено в типовых механизмах программы.

Как устроено производство в типовом ERP

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

Как устроено производство у заказчика

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

Почему нельзя было просто «сделать правильно»

Напрашивается очевидный ход: перестроить процессы и внедрить типовое планирование.
Проблема в том, что это ловушка. Чтобы перестроить производство, нужна готовая, полностью работающая система, которая будет выдавать задания и контролировать их выполнение. Но внедрить такую систему невозможно, пока процессы не перестроены: они не вписываются в логику программы.
Классическая «курица и яйцо». Плюс ещё два ограничения:
Производство нельзя остановить. Даже частично. Нельзя выделить один экспериментальный цех и постепенно переводить его на новую схему: либо всё, либо ничего.
Процессы работают и приносят прибыль. Менять всё разом, пока система ещё не готова, рискованно и бессмысленно.

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

Андрей
техлид проекта

Откуда вообще брать данные о производстве?

Мы стали искать хоть какой-то источник информации о том, что происходит в цехах. Готовая продукция, которая периодически появляется на складе, такой картины не даёт.
Ключ нашёлся в неожиданном месте: сдельная оплата труда.
Вся работа на производстве оплачивается сдельно. Каждая операция (набивка, шов, упаковка) тарифицирована. Всего в системе чуть больше 5 000 видов работ с индивидуальными расценками. Причём «последний шов» на одной игрушке и «последний шов» на другой считаются разными работами с разными ценами.
Эти данные исправно собирались — на бумажках, с задержкой — но собирались, потому что от них зависела зарплата.
Мы поняли: если знать, сколько каких работ выполнено по конкретному изделию, можно восстановить картину производства: какие этапы пройдены, сколько изделий в работе, что где находится.
Оставалось придумать, как эти данные быстро собирать и переводить в язык, понятный ERP.

Подход первый: ввод данных напрямую в этапы

Мы доработали типовой документ «Этап производства» — добавили возможность фиксировать выпуск не от количества готовых изделий, а от выполненных работ (трудозатрат). Логика: вносим список работ → нажимаем кнопку → система считает выпуск.
Очень быстро стало понятно, что этот путь не работает.
Типовой интерфейс этапов тяжёлый и перегруженный, для ввода тысяч записей в день он не годится. Но главная проблема глубже: люди, которые вводят данные, не знают, к какому производственному этапу относится их работа. Они знают изделие — и всё. Номер этапа для них ничего не значит. Этапы приходилось подбирать вручную, по очереди, один за другим.

Подход второй: групповой ввод

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

Подход третий: убрать бумажку

Мы приняли принципиальное решение: данные должны попадать в систему сразу, без промежуточной бумажки. Вводить их должны те же люди, что раньше писали на бумажках, только напрямую в программу.
Для этого мы разработали с нуля специальное рабочее место: АРМ первичного ввода работ. При проектировании стояла одна задача: предельный минимализм. Только то, что раньше писали на бумажке: изделие, участок, количество, кто сделал. Без производственных этапов, без лишних проверок, без ненужных деталей. Максимально быстро, максимально просто.
На участке упаковки пошли ещё дальше: работы фиксируются сканированием штрихкода упаковки, и данные попадают в систему мгновенно, без ручного ввода.
Для рабочих на производстве ничего принципиально не изменилось. Интерфейс получился настолько простым, что осваивать его почти не пришлось.

Как связать первичные данные с производственным учётом

АРМ решил проблему сбора данных. Но собранные данные ещё не производственный учёт. Их нужно «перевести» в трудозатраты этапов, а на их основании оформить выпуск продукции. И на каждом шаге были свои подводные камни.

Проблема: что уже разнесено, а что нет?

Если разносить данные по этапам вручную, начинается путаница: забыли, что уже отразили; продублировали; потеряли.
Чтобы этого избежать, мы создали промежуточный буфер — специальный регистр, который работает по принципу «пришло — ушло». Когда данные вводятся через АРМ, они «приходуются» в буфер. Когда разносятся в этапы, «списываются». Остаток в буфере = работы, которые зафиксированы, но ещё не отражены в учёте.
Так ничего не теряется и не дублируется.

Проблема: выпуск нельзя делать одновременно с трудозатратами

Трудозатраты можно разнести всегда: мы знаем, какие работы выполнены. А вот выпуск по этому этапу может быть невозможен, например, если ещё не хватает сырья. Поэтому выпуск оформляется отдельно, позже.

Итоговая цепочка

Вот как работает полная схема, от реальной работы в цехе до учёта в ERP:

  1. Ответственный в цехе вводит в АРМ те же данные, что раньше записывал на бумажку
  2. Данные попадают в промежуточный буфер
  3. Периодически данные из буфера разносятся в трудозатраты производственных этапов
  4. Разнесённые данные списываются из буфера
  5. На основании трудозатрат оформляется выпуск продукции
  6. Этапы продвигаются
Цепочка получилась многоступенчатая, но каждое звено в ней решает конкретную задачу, и без любого из них контур не замыкается.

Последний разрыв: склад принимает быстрее, чем производство отчитывается

Контур производственного учёта собрали. Но между производством и складом остался разрыв.
Склад принимает продукцию сразу: приехала тележка, кладовщик отсканировал и оприходовал. А данные о производственном выпуске приходят с задержкой примерно в сутки. В типовом ERP всё наоборот: сначала выпуск, потом приёмка.
Мы решили эту проблему «обратной приёмкой»: система автоматически считает все изделия на финальном этапе доступными для приёмки. Реальный выпуск по трудозатратам постепенно «догоняет» по минимально необходимому набору данных, без искажения учёта.
Но оставался ещё один подводный камень. Типовой интерфейс приёмки требует указать номер этапа, а кладовщик его не знает и знать не должен.
Мы разработали отдельное рабочее место для приёмки. Кладовщик заполняет данные со сканера и нажимает одну кнопку. Система сама находит нужный этап, создаёт приходный ордер и оформляет выпуск. Если что-то не сходится, выводит ошибку.
Дополнительный бонус: кладовщик видит в реальном времени, какая продукция прошла упаковку (данные приходят из АРМ ввода работ). Если на склад пытается попасть что-то неупакованное, это сразу видно.

Отчёты: ежедневная картина производства

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

Что получилось в итоге

Замкнутый контур учёта. Впервые фабрика видит полную цепочку: закупка сырья → работа цехов → выпуск полуфабрикатов → готовая продукция → приёмка на склад. Теперь можно посчитать реальную себестоимость каждого изделия.
Один день задержки вместо двух недель. Раньше данные о производстве попадали в систему дважды в месяц. Теперь они появляются на следующий день после выполнения работ, а на участке упаковки сразу.
Производство не перестраивали. Процессы на фабрике остались прежними, изменился только способ, которым данные о работах попадают в учёт.
Зарплата считается автоматически. Ведомость по сдельным работам формируется из тех же данных, которые используются для производственного учёта. Двойной ввод исчез.

Что дальше

Сейчас система стабилизирована и работает, и на этой основе можно двигаться дальше.
Оперативное планирование. На этапе внедрения мы протестировали возможности оперативного планирования в ERP: заполнили рабочие центры, нормы времени, прогнали сценарии. Пока производство к этому не готово: сначала нужно полностью стабилизировать то, что уже работает. Но технически всё подготовлено, и к этой теме можно будет вернуться.
Планшеты для рабочих. Сейчас данные вводит ответственный на участке. Следующий шаг: перенести ввод непосредственно на рабочие места сотрудников, выдав им специальные планшеты. Это ещё больше сократит задержку и приблизит учёт к реальному времени.

Стоимость и сроки

Проект занял 8 месяцев. Такой объем доработок блока производства в ERP стоит от 5 млн рублей. На итоговую сумму сильнее всего влияют сложность производственных процессов и то, насколько хорошо они ложатся на типовой функционал ERP.

Сталкиваетесь с похожей ситуацией?

Если ваше производство не вписывается в типовые схемы 1С:ERP, это решаемая задача.
Напишите нам — разберёмся в вашей ситуации и предложим план действий.