Мы разработали ERP-систему для масложирового производства, которая покрывает полный цикл предприятия: от журнала приёмки и лабораторных анализов до производства, склада, финансов и отгрузки. Девять модулей работают в едином контуре данных, ИИ-ассистент в ядре помогает технологам и диспетчерам, а аналитика обновляется в реальном времени. От discovery до промышленного запуска проект прошёл за шесть месяцев на стеке React, FastAPI, Supabase и PostgreSQL.
02 — Контекст
Исходная ситуация, ограничения и проблемы, которые должна была решить новая система.
Маслозавод — это непрерывный поток материала и данных. На весовую поступают машины с маслосеменами, качество сырья меняется от партии к партии, а покупатели и регуляторы требуют подтверждать качество продукции протоколами анализов и прослеживаемостью. В таком производстве каждый разрыв в учёте затрагивает сразу несколько участков.
Типичная картина в отрасли до автоматизации: приёмка, лаборатория, производство и склад ведут учёт в разрозненных таблицах и локальных программах, журналы анализов заполняются на бумаге, а данные о партии теряются на стыках между участками. Руководство получает сводные цифры с задержкой в дни, и решения принимаются по устаревшей картине.
Задача, которую мы решали: спроектировать и запустить единую ERP, где весь контур завода — от машины на весовой до отгрузки готовой продукции — живёт в одной системе, с лабораторным контролем качества, сквозной прослеживаемостью партий, аналитикой в реальном времени и ИИ-ассистентом в ядре.
Приёмка, лаборатория, производство и склад ведут данные в отдельных таблицах и программах. Одна и та же партия существует в нескольких версиях, цифры не сходятся, а на сверку между участками уходят часы работы специалистов.
Журналы приёмки и анализов заполняются вручную. Историю показателей качества по конкретной партии или поставщику восстановить трудно, а отклонения от нормативов замечают уже после того, как сырьё ушло в переработку.
Невозможно быстро ответить, из какого сырья произведена конкретная партия масла и куда она отгружена. Претензии покупателей и запросы регуляторов превращаются в многодневные расследования по бумажным журналам и таблицам.
03 — Возможности
Ключевые сценарии и рабочие модули, собранные в единую систему.
Электронный журнал приёмки фиксирует каждую машину с сырьём: поставщика, вес, время, результаты входного контроля. Лаборант вносит показатели качества прямо в карточку партии, а система хранит полную историю анализов. Отклонения от нормативов подсвечиваются в момент ввода, поэтому спорное сырьё не уходит на производство незамеченным — по сути это LIMS-контур внутри ERP.
Каждая партия получает сквозной идентификатор ещё на весовой и сохраняет его через все переделы. Система показывает цепочку целиком: из каких партий сырья произведена продукция, какие анализы по ним проводились и в какие отгрузки она попала. Это основа для работы с претензиями, отзыва партий и подтверждения качества перед покупателями и регуляторами.
Модуль фиксирует переработку по сменам и переделам: сколько сырья запущено, сколько масла и сопутствующей продукции получено, какие потери зафиксированы. Диспетчер видит загрузку линий и выработку в реальном времени, а технолог сравнивает фактический выход с нормативным — расхождения заметны в момент возникновения, а не в сводке в конце месяца.
Складской модуль ведёт учёт сырья, полуфабрикатов и готовой продукции по партиям и местам хранения. Приход и расход списываются автоматически по данным приёмки, производства и отгрузок, поэтому остатки в системе совпадают с фактическими. Инвентаризации проходят быстрее, а пересортица и «потерянные» партии перестают быть нормой работы склада.
Модуль закупок ведёт поставщиков, договоры и график поставок сырья. Заявки формируются с учётом остатков на складе и потребностей производства, а история качества по каждому поставщику подтягивается из лабораторного модуля. Отдел закупок видит, чьё сырьё стабильно проходит контроль, и использует эти данные в переговорах о цене и объёмах.
Коммерческий модуль ведёт заказы покупателей, резервирование продукции на складе и оформление отгрузочных документов. Менеджер видит доступные к продаже остатки в реальном времени и статус каждого заказа. Данные о партии, включая историю анализов, привязаны к отгрузке — вопросы покупателей о качестве закрываются выпиской из системы, а не перепиской с лабораторией.
Финансовый модуль сводит взаиморасчёты с поставщиками и покупателями, платежи и себестоимость. Себестоимость партии считается на фактических данных: закупочных ценах сырья и результатах производства, а не на усреднённых нормативах. Руководство видит маржинальность по продуктам и направлениям без ручных сводок, в одном интерфейсе с производственной картиной.
Логистический модуль связывает входящие поставки сырья и исходящие отгрузки в единый поток: транспорт на территории, очередь на весовой, статусы погрузки и разгрузки. Диспетчер управляет движением машин по заводу и видит узкие места заранее — это особенно важно в пиковые недели уборочной, когда поток сырья на приёмку возрастает кратно.
ИИ-ассистент встроен в ядро системы, а не подключён сбоку: у него есть доступ к данным всех девяти модулей. Технолог, диспетчер или руководитель задаёт вопрос обычным языком — про остатки, выход продукции, историю анализов партии — и получает ответ с цифрами из системы. Ассистент также подсвечивает аномалии в показателях, на которые стоит посмотреть человеку.
04 — Архитектура
Технологии выбраны под нагрузку, интеграции и дальнейшее развитие продукта.
Интерфейсы ERP обслуживают разные роли — лаборанта, диспетчера, кладовщика, менеджера, руководителя — и у каждой свои экраны и плотность данных. React с его компонентной моделью позволил собрать библиотеку переиспользуемых таблиц, карточек партий и форм, а состояние интерфейса обновляется в реальном времени без перезагрузки страниц.
Асинхронный Python-фреймворк хорошо подходит для системы, где параллельно идут события приёмки, производства и отгрузок, а аналитика должна отдаваться без задержек. Строгая валидация данных через Pydantic важна для промышленного учёта, а экосистема Python естественно стыкуется с ИИ-частью системы — ассистент и бизнес-логика живут в одном стеке.
Прослеживаемость — это длинные цепочки связанных сущностей: партии сырья, анализы, переделы, остатки, отгрузки. Реляционная модель PostgreSQL с внешними ключами и транзакциями гарантирует целостность этих цепочек, а индексы и оконные функции позволяют считать производственную аналитику прямо в базе, без отдельного аналитического хранилища на старте.
Supabase дал управляемый PostgreSQL с готовой аутентификацией, разграничением доступа на уровне строк и realtime-подписками из коробки. Для проекта со сроком шесть месяцев это сэкономило недели инфраструктурной работы: команда занималась предметной областью — лабораторией, прослеживаемостью, производством, — а не сборкой базовых сервисов вокруг базы данных.
05 — Процесс
Последовательность работ от исследования задачи до запуска и проверки результата.
Изучили, как партия проходит по заводу: весовая, лаборатория, производственные переделы, склад, отгрузка. Зафиксировали, где данные рождаются, где теряются и кто ими пользуется. Итог этапа — карта процессов и согласованные границы будущей системы.
06 — Итог
Что создано в рамках проекта: рабочий контур, реализованные возможности и подтверждённые факты.
За шесть месяцев мы прошли путь от discovery до промышленного запуска ERP для перерабатывающего производства. Девять модулей — от журнала приёмки и лаборатории до финансов и сквозной логистики — работают в едином контуре данных: партия прослеживается от машины на весовой до отгрузки, а история анализов хранится в её карточке.
Аналитика обновляется в реальном времени, поэтому диспетчер, технолог и руководитель смотрят на одну и ту же актуальную картину, а не на сводки разной давности. ИИ-ассистент в ядре системы отвечает на вопросы по данным всех модулей и подсвечивает аномалии. Проект вела наша команда полного цикла: аналитика, проектирование, разработка, внедрение и поддержка — в одних руках.
6
месяцев от discovery до запуска
9
модулей в едином контуре данных
Сквозной ID
связывает партию от приёмки до отгрузки
AI
ассистент в ядре системы
Детали проекта
Кейс опубликован без имени клиента: соглашение о конфиденциальности закрывает название компании, внутренние производственные показатели и коммерческие данные. Для enterprise-разработки в промышленности это обычная практика — заводы редко разрешают публиковать свою операционную «кухню».
Зато инженерная сторона кейса открыта полностью: как устроены прослеживаемость партий и лабораторный контур, из каких модулей собрана система, на каком стеке и в какие сроки она построена. Часть деталей отражает нашу типовую практику в проектах для перерабатывающих производств — данных конкретного завода они не раскрывают.
FAQ
Далее
Расскажите о задачах вашего бизнеса — предложим архитектуру и оценим сроки
Телеграмм
Делимся визуально привлекательными фрагментами наших последних веб-проектов.
ВКонтакте
Пишем о интересных технических решениях и вызовах в разработке.
MAX
Демонстрируем дизайнерские элементы наших веб-проектов.
TenChat
Деловые связи, кейсы и экспертные публикации.
Рассылка
© 2025-2026 МАЙПЛ. Все права защищены.
