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

Главное о кейсе

• Сделали калькулятор вторичных продаж компании «Альпинтех».
• «Альпинтех» — крупнейший производитель лакомств для домашних питомцев. Его продукция под брендами TiTBiT, «Синий кот» и Biff есть в каждом супермаркете страны и во всех маркетплейсах.
• Калькулятор нужен для вывода новых товаров на рынок и их презентации крупнейшим оптовым покупателям.
• Внедрение позволило сократить расчеты по вторичным предложениям оптовым покупателям с нескольких дней до нескольких минут.

• We have created a secondary sales calculator for Alpintech (Альпинтех) company.
• Alpintech is one of the largest pet treat manufacturers. Its products under the brands of TiTBiT, Siniy kot (Синий кот) and Biff can be found in every supermarket of the country and in all marketplaces.
• The calculator is designed for new products to enter the market and to present them to large wholesale customers.
• Implementation has made it possible to reduce calculations for secondary offerings to wholesale customers from several days to a few minutes.

Как проект изменил жизнь пользователей

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

До внедрения калькулятора расчеты занимали несколько дней.
1. Сейчас система сама предлагает товары на замену, анализируя показатели продаж по сетям.
2. Автоматически подбираются лучшие товары на замену выбранному. Рассчитывается прогноз по росту прибыли.
3. Формируется коммерческое предложение.
4. На каждом шаге менеджер может вмешаться и скорректировать выбранные позиции, проведя фильтрацию/поиск по разным показателям: количество продаж на торговую точку, выручка, маржа или все вместе.

The customer is constantly working on analyzing the sales of its product range. New items regularly enter the market, and if they sell better than the previous analogues, the production is restructured.
The calculator of secondary sales has speeded up the calculations for commercial offers tenfold. It has freed the sales department from routine calculations and human error.

Before the calculator was implemented, calculations took several days.
1. Now the system itself offers replacement goods by analyzing the sales indicators for chains.
2. The best products to replace the selected one are automatically chosen. A forecast for profit growth is calculated.
3. A commercial offer is formed.
4. At each step, the manager may intervene and adjust the selected items by filtering/searching by various indicators: number of sales per outlet, revenue, margin, or all of the above.

Бизнес-задача и ее решение

«Альпинтех» начинал с небольшого производства, а сейчас в его каталоге сотни позиций. Объем производства измеряется миллионами упаковок.
Системы расчетов, состоящие из большого количества скриптов и таблиц, не успевали за ростом бизнеса. Скриптов становилось слишком много, ввод в систему новых расчетов усложнялся. Это приводило к тому, что сотрудники TiTBiT тратили большое количество времени на задачи, которые можно автоматизировать и за счет этого ускорить в разы.
Аналитики «Альпинтеха» разработали методику расчета всех необходимых показателей: их частично считали вручную, частично в Excel, частично с помощью скриптов.
Мы собрали все расчеты в единый калькулятор коммерческих предложений. Он берет нужные данные из единой базы, сам проводит сравнения, отбирает выгодные пары и отображает это все на одной странице. Менеджерам остается только принять решение.
Ключевые клиенты компании — крупные сети. Им интересны большие партии по малому количеству позиций. Чтобы сделать лучшее предложение, менеджер рассчитывает рейтинг товаров.
На странице рейтинга номенклатуры виден рейтинг каждой позиции по критериям, разработанным заказчиком. Собирается как общий рейтинг, так и индивидуальный под каждого клиента. На его основе менеджеры по продажам получают рекомендации, кому из клиентов что предложить.
Вот отчеты, которые мы разработали:

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

Alpintech started with a small production, and now its catalog features hundreds of items. The output is measured in millions of packages.
The systems of calculations consisting of numerous scripts and spreadsheets didn’t use to keep up with the business growth. There were too many scripts, and entering new calculations into the system became more difficult. This made TiTBit employees to spend a lot of time on tasks that could be automated and thus accelerated many times over.
Alpintech's analysts developed a method for calculating all the necessary indicators: some were calculated manually, others – in Excel or using scripts.
We collected all the calculations in a single calculator of commercial offers. It takes the necessary data from a single database, makes comparisons, selects profitable pairs and displays it all on one page. Managers only have to make a decision.
The company's key clients are large chains. They are interested in large batches and a small number of items. To make a better offer to them the manager calculates product ratings.
The product rating page shows the rating of each item according to the criteria developed by the customer. Both an overall rating and an individual rating for each customer are made. Based on it, sales managers get recommendations on what to offer to which customer.

Here are the reports we have developed:
• Pair selection. The report is based on sales data provided by large buyers, retail chains.
• Comparison of goods by ten parameters: shelf price including VAT, quantity, revenue, margin, etc.
• A commercial proposal in which 30 parameters for current, planned indicators and investments for a pair of products are calculated. The system itself analyzes them and offers a solution for replacing one product with another.
• The product rating is calculated according to various criteria.
• Configuration report. This kind of report makes it possible to flexibly configure reports for any combination of parameters and periods, filter by any parameter, collapse indicators, etc.

Крафт (мастерство), реализация, технические детали

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

1. Загрузка 20 000 разных настроек on-demand
На сервисе есть различные dropdown-фильтры: фильтрация по имени номенклатуры, группе товаров, поставщикам. В начале проекта база данных была небольшая, и все данные загружались по новой на каждом открытии страницы. Со временем вес этих данных достиг 30 Гб. Порой опции фильтров доставались по 10 секунд.
Первая оптимизация была простая — не грузить каждый раз настройки, а сохранять их на клиенте. Прогресс есть, но первая 10-секундная загрузка никуда не делась.
Было предложено решение с экраном загрузки. Пользователь заходит на сервис, тот показывает экран загрузки, грузит все возможные настройки и сохраняет их на клиенте.
Следующая итерация и решение, которое в итоге приняли, — загрузка on-demand. Когда пользователь заходит на какую-то страницу и в его сессии не сохранены нужные опции, то он грузит только те настройки, которые нужны для работы с этой страницей, и сохраняет их. А на бэкенде добавили кеш этих опций с регулярным прогревом. Скорость в разы выросла, и в UX ничего не потеряли.

2. LRU cache в многопоточной среде
На странице формирования коммерческого предложения находятся три вкладки. Эти три вкладки используют один отчет, но позволяют по-разному с ним взаимодействовать. Его построение кешировали с помощью LRU cache, и все вкладки стали работать быстро.
Но иногда, в случайные моменты, в случайном порядке отчет не брался из кеша, а перестраивался. Вот как Евгений Макунев описывает поиск решения проблемы:
— Это очень меня удивило, и я два дня побегал, пытаясь найти причину. Думал, может, параметры разные передаются, может, эти параметры не хешируемые, может, хеш-функция, которая создает ID для вызова, зависит от окружения. Ни одна теория не подтвердилась.
Когда я общался с другом, он меня спросил: «А что, если построение этого отчета вызывается из разных потоков?». Как мысль — может, но в документации LRU cache ведь сказано, что эта функция thread-safe. Получив эту зацепку, я пошел проверять. Да, действительно, callback'и страниц исполняются из разных потоков. Немного поэкспериментировал с LRU cache в многопоточной среде и сделал забавное открытие. Под thread-safe создатели функции не закладывали, что потоки делятся этим кешем, для каждого потока создается свой LRU cache. И если два callback'а работают в одном потоке, а третий в другом, то третий будет строить отчет заново. Задача решилась переносом кеша со стороны Python в Redis, благо на проекте он уже был как очередь сообщений.

3. Метод «падать быстро»
Это, по словам Евгения Макунева, «прикольный подход» к разработке, который хорошо виден на примере сохраненных настроек. На нескольких отчетах есть функционал по сохранению выставленных настроек, и при применении какой-либо ее нужно валидировать. Вот вы подгрузили настройки, проверили их на корректность, и обнаружилось, что некоторые больше не актуальны и их нельзя применить. Ошибка не критичная, и ее можно просто игнорировать, удалив не прошедшие проверку настройки. Но таким образом вы не решаете проблему, а просто замалчиваете ее. Как вообще эти настройки были созданы? В какой момент они стали не валидными?
Интегрировав метод «падать быстро», мы поменяли подход к проблеме. Начали предупреждать пользователя об ошибках и получили важную информацию — возможные настройки меняются, но миграции для обновления сохраненных пользователями настроек написаны не были.
Чем больше ваша система, тем больше в ней будет багов. Но не все из них критичные, и система вполне может работать несмотря на них. Велик соблазн умолчать об ошибке и продлить функционирование системы, но это, скорее всего, ударит по вам в будущем. Она продолжит портить пользовательский опыт и может привести к более серьезным ошибкам, когда найти настоящий корень проблемы будет очень сложно.
Ошибка возникла, и, если ваше решение не может ее обработать, то сообщите о ней, чтобы разработчики могли написать фикс.

The main difficulty of the project was to optimize the processing of a large amount of data in different formats. Several interesting solutions were used to accomplish this.

1. Loading 20 000 different on-demand settings
The service has various dropdown filters: filtration by item name, product goods, suppliers. At the beginning of the project, the database was small, and all data was loaded all over again each time the page was opened. Over time, the volume of this data reached 30 GB. Sometimes filter options took 10 seconds to load.
The first optimization was simple – not to load the settings each time but to save them on the client. It was a step toward progress but the first 10-second loading didn't go anywhere. We offered a loading screen. The user logs in to the service, it shows the loading screen, loads all possible settings and saves them on the client.
The next iteration and the solution we finally implemented was on-demand loading. When a user goes to a page and the necessary options are not saved in their session, they load only the settings, which are needed to work with this page and save them. On the backend, we added a cache of these options with a regular warm-up. The speed has increased several times, and the UX has not lost a thing.

2. LRU cache in a multithreaded environment
There are three tabs on the page for generating a commercial proposal. These three tabs use the same report but allow to interact with it in different ways. Its build was cached using LRU cache, and all tabs started working fast.
But sometimes, at random moments, in random order, the report was not taken from the cache, but rebuilt. Here is how Evgeny Makunev describes the search for a solution to the problem:
“This surprised me very much, and I spent two days trying to find the cause. I thought maybe different parameters are transferred, maybe these parameters are not hashed, maybe the hash function that creates the ID for the call depends on the environment. None of the theories proved to be true.
When I was talking to a friend, he asked me, “What if building this report is called back from different threads?”. As a thought – it could, but the LRU cache documentation says that this function is thread-safe. Having gotten that clue, I went to check it out. Yes, indeed, page callbacks are executed from different threads. I experimented a bit with LRU cache in a multithreaded environment and made a funny discovery. By thread-safe the creators of the function did not mean that threads share this cache, each thread creates its own LRU cache. And if two callbacks work in one thread and the third in another, then the third thread will build the report anew. The problem was solved by moving the cache from Python to Redis, fortunately, it was already in the project as a message queue.”

3. “Fall fast” method
According to Makunev Evgeny, it's a 'cool approach' to development, which can be clearly seen in the example of saved settings. Several reports have functionality for saving the settings, and when applying any of them, it must be validated. So, you loaded the settings, checked them for correctness and found out that some of them are not relevant anymore and can’t be applied. The error is not critical and you may just ignore it by deleting the settings that didn't pass the check. But this way you do not solve the problem but just keep it quiet. How were these settings created in the first place? At what point did they become invalid?
By integrating the “Fall fast” method we changed the approach to the problem. We started to warn the user about errors and got important information – possible settings are changing but migrations to update the settings saved by users were not written.
The larger your system is, the more bugs it will have. But not all of them are critical, and the system can work despite them. It is tempting to keep quiet about a bug and keep the system running longer, but this will most likely hit you in the future. It will continue to spoil the user experience and can lead to more serious errors when finding the real root of the problem will be really hard.
The bug has occurred, and if your solution can't handle it, then report it so the developers can write a fix.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Работа велась по договору T&M. Бизнес-аналитика и тестирование — на стороне заказчика.

The work was carried out under a T&M contract. Business analytics and testing — on the customer's side.

Прочая информация о кейсе

Проект вполнен в тесном контакте с техническим отделом заказчика. Проект является внутренней системой заказчика. Для демонстрации сделан тестовый доступ с небольшим объемом тестовых данных.
Чтобы появились данные, нужно нажать на шестеренку справа и выбрать сеть и клиента, затем выбрать отчет.
Ссылка https://calc.titbit.softorium.pro
Памятка по данным:
- В тестовой базе 7 клиентов
- Всего 12,404 номенклатуры клиентов и 3,306 «Альпинтех»-номенклатур
- Данные по продажам с 2022-01-01 по 2024-07-01

Все имена клиентов и коды номенклатур скрыты.
Демо функционала https://disk.yandex.ru/i/7pArvSx0myIKQg

The project is a customer’s internal system. Test access with a small volume of test data has been made for demonstration purposes.
For the data to appear, you need to click on the gear to the right and select a network and a client, then select a report.
Link https://calc.titbit.softorium.pro
Data memo:
- There are 7 clients in the test database
- There is a total of 12,404 clients’ nomenclatures and 3,306 Alpintech nomenclatures
- Sales data from 2022-01-01 to 2024-07-01

All clients’ names and nomenclature codes are hidden.
Demo of the functionality https://disk.yandex.ru/i/7pArvSx0myIKQg

Скриншоты