ERP для масложировой отрасли

Обновлено:
CRM Системы6 месяцевNDA

Мы разработали ERP-систему для масложирового производства, которая покрывает полный цикл завода производительностью до 500 тонн в сутки: от журнала приёмки и лабораторных анализов до производства, склада, финансов и отгрузки. Девять модулей работают в едином контуре данных, ИИ-ассистент в ядре помогает технологам и диспетчерам, а аналитика обновляется в реальном времени. От discovery до промышленного запуска проект прошёл за шесть месяцев на стеке React, FastAPI, Supabase и PostgreSQL.

ERP для масложировой отрасли

Задача

Маслозавод — это непрерывный поток материала и данных. Каждые сутки на весовую приезжают десятки машин с маслосеменами, качество сырья меняется от партии к партии, а покупатели и регуляторы требуют подтверждать качество продукции протоколами анализов и прослеживаемостью. Чем выше производительность — а здесь речь о заводе до 500 тонн в сутки, — тем дороже обходится каждый разрыв в учёте.

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

Задача, которую мы решали: спроектировать и запустить единую ERP, где весь контур завода — от машины на весовой до отгрузки готовой продукции — живёт в одной системе, с лабораторным контролем качества, сквозной прослеживаемостью партий, аналитикой в реальном времени и ИИ-ассистентом в ядре.

Разрозненный учёт

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

Бумажная лаборатория

Журналы приёмки и анализов заполняются вручную. Историю показателей качества по конкретной партии или поставщику восстановить трудно, а отклонения от нормативов замечают уже после того, как сырьё ушло в переработку.

Нет прослеживаемости партий

Невозможно быстро ответить, из какого сырья произведена конкретная партия масла и куда она отгружена. Претензии покупателей и запросы регуляторов превращаются в многодневные расследования по бумажным журналам и таблицам.

Что делает система

Приёмка сырья и лаборатория

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

Прослеживаемость партий

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

Производственный учёт

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

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

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

Закупки сырья

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

Продажи и отгрузки

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

Финансовый контур

Финансовый модуль сводит взаиморасчёты с поставщиками и покупателями, платежи и себестоимость. Себестоимость партии считается на фактических данных: закупочных ценах сырья и результатах производства, а не на усреднённых нормативах. Руководство видит маржинальность по продуктам и направлениям без ручных сводок, в одном интерфейсе с производственной картиной.

Сквозная логистика

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

ИИ-ассистент в ядре

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

Технологический стек

React

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

FastAPI

Асинхронный Python-фреймворк хорошо подходит для системы, где параллельно идут события приёмки, производства и отгрузок, а аналитика должна отдаваться без задержек. Строгая валидация данных через Pydantic важна для промышленного учёта, а экосистема Python естественно стыкуется с ИИ-частью системы — ассистент и бизнес-логика живут в одном стеке.

PostgreSQL

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

Supabase

Supabase дал управляемый PostgreSQL с готовой аутентификацией, разграничением доступа на уровне строк и realtime-подписками из коробки. Для проекта со сроком шесть месяцев это сэкономило недели инфраструктурной работы: команда занималась предметной областью — лабораторией, прослеживаемостью, производством, — а не сборкой базовых сервисов вокруг базы данных.

ReactFastAPISupabasePostgreSQL

Как шла разработка

Discovery и аудит процессов

Готово

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

Проектирование архитектуры

Готово

Спроектировали модель данных вокруг партии как центральной сущности — именно она связывает все девять модулей. Выбрали стек React, FastAPI, Supabase и PostgreSQL, заложили в архитектуру realtime-обновления и место для ИИ-ассистента в ядре, а не как внешней надстройки.

MVP: приёмка и лаборатория

Готово

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

Итерации по модулям

Готово

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

Внедрение и обучение

Готово

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

Поддержка и развитие

Готово

После промышленного запуска система перешла в режим поддержки и развития: мы следим за производительностью, расширяем аналитику и возможности ИИ-ассистента по мере того, как в системе накапливаются производственные данные и появляются новые запросы от завода.

Результаты

За шесть месяцев мы прошли путь от discovery до промышленного запуска ERP, которая покрывает завод производительностью до 500 тонн в сутки. Девять модулей — от журнала приёмки и лаборатории до финансов и сквозной логистики — работают в едином контуре данных: партия прослеживается от машины на весовой до отгрузки, а история анализов доступна в пару кликов вместо поиска по бумажным журналам.

Аналитика обновляется в реальном времени, поэтому диспетчер, технолог и руководитель смотрят на одну и ту же актуальную картину, а не на сводки разной давности. ИИ-ассистент в ядре системы отвечает на вопросы по данным всех модулей и подсвечивает аномалии. Проект вела наша команда полного цикла: аналитика, проектирование, разработка, внедрение и поддержка — в одних руках.

6

месяцев от discovery до запуска

9

модулей в едином контуре данных

500

тонн в сутки — мощность завода

AI

ассистент в ядре системы

Почему кейс без имени клиента

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

Зато инженерная сторона кейса открыта полностью: как устроены прослеживаемость партий и лабораторный контур, из каких модулей собрана система, на каком стеке и в какие сроки она построена. Часть деталей отражает нашу типовую практику в проектах для перерабатывающих производств — данных конкретного завода они не раскрывают.

Вопросы о проекте

Обсудим похожий проект?

Расскажите о задачах вашего бизнеса — предложим архитектуру и оценим сроки