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

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

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

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

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

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

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

С нашим клиентом уже работала BI-команда, они помогали с аналитикой. Они же собрали данные, систематизировали процессы и визуализировали их в виде понятной бизнес-структуры. Именно на основе этой работы сформировалось ТЗ, с которым в проект пригласили нас. Мы взяли на себя проектирование интерфейсов, разработку логики и сборку цифрового решения, а аналитики помогали разбираться в процессах клиента.

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

Проект собран на Next. js, надежном React-фреймворке. Он подходит для корпоративных систем с модульной архитектурой.

Наша CRM интегрирована с базой данных (PostgreSQL), которая уже была у клиента. Мы обеспечили ее совместимость с Pyramid Analytics, которую клиент использует для бизнес-аналитики. При этом CRM-система полностью автономна: она не зависит от Pyramid, а просто транслирует в нее данные, как в BI-витрину.

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

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

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

Затем за 3 недели мы собрали собственную UI-библиотеку. Ее компоненты — кнопки, инпуты, селекты — отрисовали и адаптировали самостоятельно, с нуля или на основе готовых паттернов. Частично использовали Ant Design как вспомогательную библиотеку.

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

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

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

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

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

Вот как шло поэтапное создание системы:

1. Blend Calculator — первый и один из самых важных модулей, который стал фундаментом для разработки остальных частей системы.
– 240 часов
– Проектирование UX и UI, разработка
– Много обсуждений и итераций

2. Blend Ticket — самый крупный и сложный модуль со множеством этапов, логик и доступов.
– 420 часов
– Проектирование UX и UI, разработка
– Много итераций и внедрений новых идей по ходу работы

3. Calendar — модуль визуализации всех заказов.
– 74 часов
– Проектирование и разработка на основе UI-библиотеки
– Минимум правок

4. Inventory — раздел с регистрацией заявок, самый простой в реализации.
– 36 часов
– Проектирование UX и UI, разработка
– Быстрое внедрение без сложностей

Теперь немного расскажем про каждый модуль в отдельности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Прохождение производственного цикла
Тикет проходит следующие этапы:

• Лаборатория — проверяет и утверждает рецептуру.
• Менеджмент — назначение ответственных.
• Производство — выполняет смешивание компонентов.
• Контроль качества — фиксирует пробы, параметры, результаты.
• Финальная проверка — добавляются подписи ответственных и фотографии отгруженного продукта (например, в цистерне).

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

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

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

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

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

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

• Начните с карты процессов. Посмотрите, где вы теряете деньги, время и людей. Часто операционка хранится в голове сотрудников или размазана по табличкам. Без единой картины будет сложно понять, что именно нужно оцифровывать.
• Не пытайтесь охватить все сразу. Лучше идти от простого к сложному. Например, сначала зафиксировать заявки, потом — расчеты, и только потом — производственный цикл. Это и быстрее, и понятнее для команды.
• Слушайте тех, кто работает руками. Они подскажут, где узкие места, и что действительно нужно и возможно автоматизировать.
• Считайте, сколько теряете. Потери от ручного труда сложно заметить, пока не начнешь их фиксировать. Разрозненные таблицы тянут за собой ошибки, задержки и перерасход.
• Работайте с аналитиками. В идеале перед разработкой стоит этап аудита и структурирования процессов, как в нашем проекте. Это помогает не переплатить за ненужное и не упустить важные мелочи.
• Система должна работать для вас, а не наоборот. Типовые решения — это удобно, но не всегда эффективно. Иногда выгоднее сделать кастомный сервис, пусть простой, но свой.