Как мы помогли заводу в Техасе начать экономить от $159 025 в год, разработав MVP кастомной ERP

До недавнего времени в этой техасской химической компании все держалось на табличках, бумаге и людской памяти. Но масштаб бизнеса требовал другого подхода: ручной учет не справлялся, заказы терялись, излишки сырья замораживали бюджет. За почти 5 месяцев мы разработали для компании MVP ERP-системы, за счет которой она экономит более $159 000 в год на оптимизации ручного труда, предотвращении ошибок и улучшении менеджмента. Вот как это было.

Клиент

Наш клиент — крупный производитель нефтехимической продукции, в том числе ароматических и алифатических растворителей, синтетических изопарафинов, поли­изобутиленов, ПАО (полиальфаолефинов) и других специальных химикатов.

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

Задачи проекта:

— Создание и контроль заказов от заявки до отгрузки.

— Фиксация этапов производства с возможностью отслеживания на каждом шаге.

— Автоматизация расчета рецептур для смесей с учетом остатков, цен и характеристик компонентов.

— Жесткая система уровней доступа, чтобы каждый сотрудник видел только свою часть процесса.

— Визуальный контроль: статусы каждого заказа, подписи ответственных, прогресс по этапам и календарь всех процессов.

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

— Раздел «Инвентарь». Раздел для фиксации входящих запросов на производство. Задает параметры заказа и запускает дальнейшие расчеты и планирование;

— Калькулятор. Этот модуль запускает производственный цикл, и чем он точнее, тем меньше ошибок дальше по цепочке. Основная задача модуля — расчет рецептур химических смесей. Он автоматически считает компоненты, учитывает остатки и себестоимость;

— Раздел «Смешивание». Центральная карточка заказа и его производственного цикла. Фиксирует этапы, статусы, ответственных и подписи на каждом шаге;

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

Что было до?

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

Вот как наш клиент описывает проблему ручного труда в компании:

«‎Работа с данными занимала значительную часть времени, что приводило к неточности заказов и, как правило, к излишним заказам и соответственно, к большему хранению продукта, чем необходимо. Это приводило к замораживанию капитала, и невозможности расширения каталога».

Для бизнеса, который постоянно растет и работает с большим объемом заказов, это создает риски: ошибки, задержки, потери.

Сначала мы погрузились в процессы производства и менеджмента внутри компании, чтобы изучить каждую деталь и переложить ее на будущую логику работы ERP-системы.

Получился следующий путь. Входная точка Inventory (здесь регистрируется заявка) → на ее основе производится расчет в Blend Calculator → формируется Blend Ticket → запускается производственный процесс. И это все отражается в Calendar.

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

Так выглядит финальная версия модуля

В итоге за 4,8 месяцев активной работы мы собрали полноценную систему, готовую для цифровизации производственных процессов клиента.

В целом проект получился суперинтернациональный за счет того, что мы плотно сотрудничали с BI-командой. Одновременно над ERP-системой работали в России, Казахстане, США, Африке и Бразилии. Переписку и созвоны вели на английском, ювелирно подгадывали даты и время встреч, а ответы на email иногда ждали почти сутки за счет разных часовых поясов. Учитывая все это, 4,8 месяцев с нуля до запуска — неплохой результат.

Интерфейс разрабатывали для использования как в цеху на планшетах (iOS), так и в офисе. Поэтому он должен был быть универсальным и понятным для всех сотрудников.

Под такие условия мы проектировали ERP-систему

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

На основе этого анализа и бизнес-требований мы спроектировали UX-интерфейс: определили структуру экранов, логику переходов, поведение вкладок и кнопок, сценарии использования.

Одна из главных трудностей, с которыми мы столкнулись, — высокая плотность информации.

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

С одной стороны, нужно было следовать принципам UX-дизайна (чтобы было компактно, аккуратно, интуитивно понятно). С другой стороны, задачей было реализовать не просто CRM в стандартном виде, а скорее пульт управления химическим производством, где все детали должны быть на виду. Поэтому приходилось несколько раз пересобирать интерфейс по ходу добавления новых данных.

Будущий интерфейс мы согласовывали с клиентом в ч/б-варианте: просто наглядные схемы того, какой будет структура и функционал ERP-системы. Клиент часто просил добавить новый функционал на ходу, и, как всегда, итоговые макеты сильно отличались от того, что было заложено в ТЗ.

Далее мы собирали собственную UI-библиотеку. Ее компоненты — кнопки, инпуты, селекты — отрисовали и адаптировали самостоятельно, с нуля или на основе готовых паттернов. Частично использовали Ant Design как вспомогательную библиотеку. На это ушло больше 3 недель, особенно с учетом сложностей с плотной информацией и необходимости обеспечить единый стиль.

 UI-библиотека проекта

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

Для такого типа ERP (с модульной архитектурой, кастомными интерфейсами и высокой нагрузкой) важно было выбрать стек, который обеспечивает стабильность, гибкость и масштабируемость. Мы остановились на Next.js, мощном React-фреймворке, который хорошо подходит для корпоративных решений. Он позволяет выстраивать независимые модули, легко масштабируется и хорошо работает в связке с TypeScript. 

Как передаются данные между разными сервисами, которыми пользуется компания

В качестве базы данных мы использовали PostgreSQL, которая уже была у клиента. Мы интегрировали ERP в эту инфраструктуру, чтобы не ломать привычные процессы и не дублировать данные. Отдельно настроили совместимость с Pyramid Analytics — BI-платформой, через которую клиент получает отчеты. Хотя данные передаются в Pyramid, сама ERP полностью автономна и не зависит от внешних сервисов.

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

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

Раньше из-за неточного контроля остатков компания закупала больше компонентов, чем нужно, и это приводило к потерям и заморозке средств. Теперь расчеты автоматизированы в Blend Calculator: система сверяет рецептуру с текущими остатками и исключает лишние закупки. По прогнозу аналитиков, такая оптимизация даст экономию $38 087 в год.

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

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

Начали с UX-прототипа (без цветов, просто структура и логика). После согласования прототипа собрали макеты в Figma с отображением продуктов и рецептов к ним. Клиент принял их практически без правок, и мы запустили модуль в разработку.

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

Чтобы убедиться, что ничего не сломается, этот модуль мы сразу передали на тестирование в реальных производственных условиях. Если бы калькулятор выдавал некорректные расчеты, компания могла бы понести убытки.

В целом интерфейс модуля получился аккуратным и понятным. В процессе разработки мы предложили разные режимы отображения карточек рецептов: от подробного (с версиями и компонентами) до лаконичного. Это облегчило работу в зависимости от целей сотрудника и уровня доступа. Так мы дополнительно разгрузили интерфейс, чтобы помочь пользователям держать фокус на главном в данный момент.

Разные режимы отображения данных в разделе с рецептами

Функционал

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

Так выглядит модуль Calculator, который рассчитывает рецептуру продукта

Хотя нашей главной целью было автоматизировать создание рецептуры, в этом модуле мы сохранили ручной контроль. Система помогает с расчетами, но последнее слово — за определенным сотрудником, у которого есть доступ к этой задаче.

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

Когда рецепт готов, система создает тикет. Он фиксирует, что именно нужно смешать, в каком объеме, по какой рецептуре и кто за это отвечает.

Blend Ticket устроен по принципу карточки продукта в CRM: в нем фиксируются этапы, статусы, ответственные и вся история заказа. Только вместо дизайнеров и разработчиков — лаборатория, производство, контроль качества и логистика.

На старте этот модуль выглядел проще: всего несколько вкладок, минимальный объем данных. Но по мере работы система обрастала дополнительными параметрами, логами, полями и ролями. Клиент добавлял новые хотелки и говорил, что хочет пересобрать некоторые процессы. Например, сначала нам говорили, что лабораторных фаз будет 4, но потом их стало 6.

В какой-то момент мы поняли, что вся информация в Blend Ticket просто не влезает в экран. Там, где было 5 параметров, стало 10. И все это были нужные и важные данные, без которых не обойтись (все-таки это химическое производство, где цена ошибки слишком высока). Тут нам пришлось побрейнштомить на тему, как лучше подать информацию.

Были варианты вывести информацию по скроллу, но это не всегда удобно и интуитивно понятно. В итоге решили полностью переработать этот модуль и сделать его многостраничным:

— каждую фазу производства вынесли в отдельные вкладки;

— ключевую информацию вывели на вкладку Summary, чтобы можно было быстро оценить детали продукта, не вдаваясь в подробности;

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

Интерфейс модуля Blend Ticket, где собрана вся информация по каждому продукту

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

Дополнительно в этом модуле мы добавили верхнюю панель с ключевыми параметрами: номер заказа, название продукта, объем, лот. Панель сквозная и доступна на любой вкладке Blend Tocket. Это помогает быстро сориентироваться в работе, независимо от того, какой уровень доступа у сотрудника.

Так выглядит вкладка, с которой работает лаборатория

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

Над этим экраном мы чаще всего проводили эксперименты. Как мы уже говорили, данные внутри модуля постоянно добавлялись и перемещались. По ходу работы мы сносили некоторые вкладки или делили одну на две, и источники информации для дашборда менялись. Поэтому Summary пережил несколько пересборок и в итоге получился одновременно и компактным, и информативным.

Дашборд с ключевой информацией по продукту, модуль Blend Ticket. На верхней панели отображаются главные цифры, нужные в работе

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

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

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

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

По словам клиента, именно этот раздел дал значительный вау-эффект в процессах производства:

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

Календарь стал визуальным центром системы: здесь отображаются все активные тикеты, их этапы, сроки и статус выполнения. Он позволяет контролировать загрузку и планировать работу команды.

Модуль Calendar, стандартное отображение

Изначально клиент хотел видеть только классический календарь, но в ходе обсуждений у нас появилась идея сделать второй вариант — разместить тикеты в колонки по типу канбан. Одна колонка = один день. Этот режим оказался ближе к реальному рабочему процессу, особенно в цеху. Клиент не был знаком с такой системой работы, но поддержал нашу идею и решил, что это будет полезно.

В итоге в системе реализовали оба режима: обычный календарный и канбан.

Модуль Calendar, отображение по типу канбан

Между режимами отображения календаря можно переключаться по одному клику и сортировать тикеты по статусу.

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

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

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

Разработка велась по документации, которую предоставил клиент, а правок практически не потребовалось. Мы просто сфокусировались на чистом отображении, сортировке и детализации, чтобы с этим можно было работать даже на производственном планшете.

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

Модуль Inventory, фиксирующий заказы

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

1. Фиксация запроса от клиента в Inventory

Все начинается с того, что менеджер фиксирует входящий запрос на определенный продукт и объем. Это становится стартовой точкой для производственной цепочки. Далее система помогает провести заказ через все этапы.

2. Расчет рецептуры в Blend Calculator

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

3. Формирование Blend Ticket

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

4. Прохождение производственного цикла

Тикет проходит следующие этапы:

— Лаборатория — проверяет и утверждает рецептуру.

— Менеджмент — назначение ответственных.

— Производство — выполняет смешивание компонентов.

— Контроль качества — фиксирует пробы, параметры, результаты.

— Финальная проверка — добавляются подписи ответственных и фотографии отгруженного продукта (например, в цистерне).

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

5. Отгрузка и закрытие заказа

После завершения всех этапов продукция отправляется клиенту. Как правило, в цистернах, поездом или автотранспортом. В системе обновляется статус, и тикет закрывается.

Все этапы и статусы заказов отображаются в модуле календаря. Это позволяет отслеживать загрузку, планировать производство и видеть, на каком этапе находится каждый заказ.

После запуска и тестирования базовой версии клиент уже передал пожелания и новые хотелки. Наши коллеги-аналитики сформулировали это в ТЗ. В первую очередь будем разрабатывать модуль QC Control, который поможет оптимизировать контроль качества, учет отклонений и приемку продукции. Сейчас, по словам клиента, сервис экономит $159 025 в год, а с внедрением нового модуля эта цифра вырастет.

Дополнительно мы видим потенциал в развитии аналитического блока: на основе накопленных данных можно построить визуальные отчеты, графики и дашборды. Это можно будет делать прямо внутри своей ERP-системы и не зависеть от внешнего ПО. Раздел аналитики позволит не просто управлять процессами, но и видеть их в динамике, принимать решения на основе цифр и прогнозировать загрузку.

Сегодня, по данным, которые предоставил наш клиент, внедрение новой ERP-системы уже экономит ощутимые суммы. С каждым годом компания будет экономить все больше и больше.

ROI 1-й год: 63%

ROI 2-й год: 163%

Срок окупаемости — 7 месяцев.