Как ускорить расчёты на производстве лакомств для животных в десятки раз: кейс TiTBiT
«Альпинтех» производит лакомства для животных. Вы знаете продукцию компании по брендам TiTBiT, «Синий Кот» и Biff. И наверняка замечали эти марки на полках магазинов, даже если у вас нет домашних питомцев. Вместе с техническим отделом клиента мы учим их систему делать производственные и коммерческие расчёты за минуты. Сейчас расскажем как.
Суровые сибирские разрабы помогают большим производствам
Привет! Это «Софториум», команда с хардовым подходом к сервисам. Уже три года мы делаем сложную разработку, чтобы упрощать компаниям жизнь. В нашем послужном списке работа с SOKOLOV, R-Keeper, IIko, «Неофармом» и производителем зоотоваров TiTBiT — о нём и пойдёт речь в этом кейсе.
Мы помогаем TiTBiT масштабировать сложную систему расчётов для мониторинга ресурсов и подготовки коммерческих предложений — читайте о нашем опыте ниже и делитесь мыслями в комментариях.
TiTBiT: огромное производство лакомств для животных
Компания делает вкусные и полезные угощения для собак, кошек, грызунов и птиц, а также производит игрушки и средства для ухода за животными. Цель нашего клиента — создавать безопасную продукцию для домашних любимцев, чтобы они были здоровыми и жили долго.
TiTBiT любят и высоко ценят: на маркетплейсах товары этого бренда набирают 4,9 звёзды из 5.
В каталоге сотни позиций, а объёмы производства — огромные: компания выпускает 3,5 миллиона упаковок лакомств каждый месяц. И ежедневно поставляет свою продукцию в магазины по всей России.
Работа и развитие таких предприятий связаны с постоянными расчётами: сколько сырья заказать, когда закупить оборудование, нужны ли дополнительные производственные и складские площади. Чтобы за всем этим следить, в компании существуют сложные системы расчётов.
Прежние механики «не вывозили» — производство могло потерять миллионные контракты
На производстве клиента работают профи. Они разбираются в том, какие показатели собирать, как их контролировать и как с их помощью растить бизнес:
аналитики развивают сложнейшие системы расчётов;
программисты компании эти расчёты автоматизируют. Самое важное рассчитывают в Excel и с помощью скриптов на Python.
Дело в том, что TiTBiT не всегда была такой крупной. Когда-то компания начинала с небольшого производства, но быстро выросла. А вот системы, которые изначально не были заточены под новые объёмы, масштабировались с трудом: скриптов становилось слишком много, вводить в систему новые расчеты становилось сложнее. Иногда при расчётах возникали ошибки.
Всё это приводило к тому, что сотрудники TiTBiT тратили уйму времени на задачи, которые можно автоматизировать и за счет этого ускорить в разы. И дело тут не в человеческом факторе, а в особенностях расчётов.
Скрипты и таблицы клиента не складывались в единую структуру — они скорее были набором разрозненных мини-систем, которые только предстояло объединить. Вместе с этим по мере роста компании расчеты продолжали усложняться. Поэтому в начале 2022 года нас позвали, чтобы мы помогли адаптировать систему под растущее производство.
Сделали монитор ресурсов
При расширении компании требуется отслеживать огромное количество параметров, чтобы знать, когда построить ещё один цех, арендовать склад, нанять новых сотрудников.
Чтобы у компании были все нужные данные, мы помогли «Альпинтеху» реализовать специальную систему расчётов, спроектированную самой компанией. Она помогает прогнозировать рабочие мощности по неделям, месяцам, годам.
Прогнозирование основывается на данных из прошлого периода с учётом коэффициентов по расширению производства и позволяет отследить, насколько удалось приблизиться к плановым показателям. Сами данные для отчётов система собирает из разных сервисов: онлайн-таблиц, 1С, локальных файлов с отчётами.
При создании каждого такого отчёта видно, откуда взяты те или иные данные. Это помогает корректно планировать развитие даже при сбоях. Если в системе появится аномалия (например, какой-то из показателей примет невозможное значение), её можно будет отследить и исправить, а ошибочные данные — отфильтровать.
Разработали калькулятор коммерческих предложений
Заказчик ведёт постоянную работу по анализу сбыта своего ассортимента. В продажу регулярно поступают новые позиции, и, если они продаются лучше предыдущих аналогов, производство старых прекращается.
Вот как компания раньше работала с выводом новых товаров на рынок:
- К товарам, которые оптовые покупатели уже приобретали ранее, подбиралась похожая позиция из нового ассортимента.
- Менеджеры сравнивали их метрики между собой — в том числе с помощью рейтинга товаров, о котором мы расскажем чуть позже.
- Компания формировала коммерческое предложение, в котором заказчикам предлагались более выгодные в реализации товары.
Аналитики «Альпинтеха» разработали систему расчёта всех необходимых показателей: их частично считали вручную, частично в Excel, частично с помощью скриптов.
При небольших объёмах производства система отлично справлялась. Но по мере роста компании расчёты стали слишком трудоёмкими, и возможность ошибки при переносе и обработке данных возрастала.
Для начала мы собрали все расчёты в единый калькулятор коммерческих предложений. Он берёт нужные данные из единой базы, сам проводит сравнения, отбирает выгодные пары и отображает это всё на одной странице. Менеджерам остаётся только принять решение.
Вот как теперь это выглядит:
Подбор пар. Отчёт строится по данным продаж, которые предоставляют крупные покупатели, торговые сети. Фильтры, использующиеся для выбора товаров на замену:
статус (активные продажи, сезонность, временно введённый и т. п.);
группа товаров (лакомства для собак, кошек, витамины и т. п.);
процент покрытия (количество торговых точек, в которых продается товар);
коэффициент выручки на торговую точку;
коэффициент количества на торговую точку;
бренд, в анализе используются в том числе данные по товарам конкурентов;
потенциал на расширение.
В подборе пар товаров учитывается также маржа на одну единицу товара.
Сравнение товаров. Используется десять рассчитываемых параметров для сравнения:
цена на полке с НДС;
количество;
выручка;
маржа;
выручка на торговую точку;
маржа на одну единицу товара и другие.
Формирование коммерческого предложения. В коммерческом предложении рассчитываются 30 параметров по текущим, плановым показателям и инвестициям для пары товаров. Система сама проводит их анализ и предлагает решение по замене одного товара другим. Документ можно выгрузить в эксель-формате.
Вот так теперь выглядит КП для вторичных продаж:
Первая версия калькулятора рассчитала коммерческое предложение за 20 минут. Кажется, что это очень долго, но раньше на расчёты уходило до нескольких дней. Если держать это в уме, можно почувствовать облегчение, которое испытали сотрудники нашего клиента.
Создали страницу «Рейтинг номенклатуры»
Ключевые клиенты компании — крупные сети. Им интересны большие партии по малому количеству позиций. Чтобы сделать лучшее предложение, менеджер рассчитывает рейтинг, в котором учитывает много факторов.
На странице рейтинга номенклатуры виден рейтинг каждой позиции — по критериям, разработанным самим «Альпинтехом». Причём собирается как общий рейтинг, так и индивидуальный под каждого клиента. На его основе менеджеры по продажам получают рекомендации, кому из клиентов что предложить.
Собрали всё в единую систему
После запуска первой версии калькулятора занимались его развитием и оптимизацией. Превратили скрипты в веб-страницы — на этапе тестирования это упростило работу и ускорило расчёты. Данные оказались в едином пространстве, и получать результаты стало быстрее.
Мы провели дополнительные технические работы, чтобы система работала лучше, а пользоваться ей было удобнее:
Сделали систему логирования. С ней можно просмотреть всю цепочку выполнения шагов того или иного расчёта. Так менеджеры увидят, какие данные оказались невалидными, какие были промежуточные расчёты и какие возникли ошибки.
Написали документацию по проекту. В ней есть все инструкции по запуску, использованию и дальнейшей разработке. Новые работники легко воспользуются системой, а штатные программисты заказчика без проблем продолжат её развивать.
Настроили автоматическое обновление. Через CI/CD автоматизировали «накатывание» обновлений на сервер. Без него это приходилось бы делать вручную, что привело бы к остановкам сервера и долгим тестам каждого обновления. При этом «ручные» обновления могли проходить с ошибками, это простой человеческий фактор. Мы его устранили, а ещё сделали работу с обновлением быстрее, проще и дешевле.
Внедрили утилиту ruff для форматирования кода. Теперь код соответствует гайдлайнам стилей и выглядит единообразно. С ним будет проще работать и нам, и программистам «Альпинтеха».
Улучшили работу базы данных. Мы внедрили метод fail-fast, повысили нормальную форму базы данных, сделали индексацию ключей и дат. Вот зачем это было нужно:
с fail-fast программа в случае ошибки сразу выдаёт эту ошибку, а не пытается исполнить несрабатывающую команду, также благодаря этому методу возникшие ошибки фиксируются в таблице протокола выполнения задач;
более высокая нормальная форма повышает надежность базы данных, так как невозможно будет ссылаться на объект, которого не существует;
индексация ключей и дат повысила скорость работы всей программы в 2,5 раза — через индексацию мы собираем те поля данных, которые система использует активнее всего, и выносим их значения в отдельный столбец. Когда система ищет данные, в первую очередь она проверяет этот столбец, и за счёт этого самые часто используемые данные находятся максимально быстро.
На чём собирали систему: стек технологий
Клиент подобрал оптимальные технологии, на которых всё хорошо работало и к которым можно было присоединять всё необходимое для развития системы. Мы не стали переписывать всё с нуля и по большей части адаптировались к тому, что было у клиента:
Python;
Celery;
PostgreSQL;
Pandas.
Но всё-таки кое-что мы предложили добавить:
Docker;
Dash;
Bootstrap;
ReactJS;
Redis;
GitLab;
Alembic;
SQLAlchemy.
Минус рутина: как проведённые работы повлияют на бизнес клиента
После запуска система сможет:
обновлять свойства номенклатуры;
прогнозировать продажи и производство;
рассчитывать потребности компании в ресурсах;
проводить анализ данных всех продаж;
составлять коммерческие предложения;
делать расчёты на ввод и вывод товаров на рынок.
А ещё система спланирует расширение в соответствии с продажами. Когда менеджеры заключат контракт, данные о продаже номенклатуры автоматически попадут в систему. Если выяснится, что на дистанции производству может не хватить возможностей, его расширят: закупят оборудование и наймут людей.
К слову, раньше TiTBiT проводил такую же работу с данными, за счёт чего быстро вырвался в лидеры рынка. Но эта работа была сложной и долгой. Мы ожидаем, что обновлённая система в десятки раз сократит время на подготовку коммерческих предложений и анализ продаж.
Пока система только запускается. Но на этапе тестов у сейлз-менеджеров уже сократилась техническая часть работы: то, что раньше занимало несколько дней, теперь занимает несколько минут.
Систематизация процессов повлияет и на рост бизнеса клиента, но мы пока не знаем как. При этом очень многих сотрудников система избавит от рутины, а это значит, что они смогут посвятить больше времени и сил творческим и стратегическим задачам.
Вот такую работу мы проделали с «Альпинтехом», чтобы облегчить аналитикам их труд. Подписывайтесь на наш телеграм-канал, чтобы следить за проектом, — там мы рассказываем о новостях и делимся свежими наработками.
Ждём ваших комментариев по кейсу — пишите, что думаете о работе заказчика с разными показателями, и рассказывайте, что сами считаете в своём бизнесе.
Ура, Софториум! С первым кейсом)
Спасибо! Готовим остальные!
Вот поэтому всегда при разработке системы нужно сразу думать о её масштабировании. Чтобы потом не плодить костыли и переделывать уже готовое
Не всегда так. Иногда важнее быстрое решение прямо сейчас!
Очень много вводных стоит на старте разработки. И иногда нормальны MVP важнее дальнейших планов. А MVP часто делается на коленке в условиях жесткой экономии. Тут не совсем тот случай, но подозреваю, что когда делается первый шаг, масштабирование было "проблемой нас будущих".
Присоединяюсь к поздравлениям с первым кейсом, однако хочется некоторые пункты уточнить)
1. Где-то в технологическом стеке забыли FastAPI. Раз уж упомянут стек БД-слоя, считаю, стек веб-слоя также можно указать.
2. В баннер "новой системы расчетов", мне кажется, вместо скриншота рабочей спецификации API можно было бы поместить скриншоты самой рабочей системы (да, дальше по статье они аналогично есть, однако главная страница самой системы вместе с красивой надписью смотрелась бы идеально, опять же ИМХО).
3. ruff по-идее также часть стека, хоть и больше инфраструктурного. Мне кажется, его либо указывать в стеке, либо пункт сократить до "внедрили линтер для поддержания общего формата и качества кода".
А так - молодцы, ещё раз поздравления с первым выполненным кейсом!
Роман, спасибо за развернутый комментарий. Обязательно учтем!