Кейс - аналитика для E-commerce - часть 1
О чем проект
Мой бывший клиент познакомил меня со своим соседом, который хочет автоматизировать свою текущую деятельность и упаковать ее как продукт.
Его деятельность - расчет закупок для E-commerce компаний.
К примеру, у вас есть магазин с майками и вам нужно учесть текущий продажи, остатки и прогнозы продаж, чтобы понять сколько маек нужно закупить в следующем месяце.
Как это работает сейчас
- У него было есть несколько Excel таблиц-инструментов - для прогнозирования закупок, для отображения аналитики и финансов, для экспорта данных клиенту.
- Он работает с этими инструментами самостоятельно - на вход принимает данные о прогнозах продаж/продажах/остатках от клиента, на выходе выдает рекомендации по закупкам.
- Для каждой компании он заводит отдельный набор табличек.
- В текущем виде это невозможно продавать как продукт для сторонних пользователей.
Что он хочет
- Упаковать этот набор табличек в полноценный удобный диджитал продукт.
- Продавать этот продукт компаниям, чтобы они могли пользоваться им без его участия.
Scope проекта
Я проанализировал его таблицы и текущий процесс и вместе с ним составил ТЗ с основными требованиями.
Загрузка данных
- Расчеты строятся на различных данных, которые нужно будет загружать в систему как CSV файлы (а в будущем через API интеграцию).
- Основные данные в таблицах это товар, значение и дата, но некоторые данные отличаются - описание товаров с множеством параметров и текущие остатки без даты.
- Средний объем данных по компании - 100-300 товаров, по каждому из которых около может быть около 50 записей в БД в разных таблицах.
- Данные могут обновляться пользователем каждую неделю и должны полностью перезаписывать существующие данные.
Расчеты
- Агрегируя данные из нескольких таблиц, нужно расчитывать прогноз по ряду параметров на несколько месяцев вперед.
- Данные следующего месяца завязаны на предыдущем - нельзя просчитать данные для декабря, не просчитав данные для ноября и тд. вплоть до текущей даты.
- В интерфейсе есть 1 изменяемый параметр - сколько будет закуплено товара в конкретный месяц. Он может быть изменен пользователем в интерфейсе для любого месяца и влияет на расчеты для последующих месяцев. Перерасчет параметров должен отображаться в интерфейсе моментально.
Версионирование
- Пользователь изменяет параметр, чтобы посмотреть развитие событий и может создать некий сценарий - к примеру товар задержали и он не пришел во время или его резко раскупили. Он должен иметь возможность внести изменения (User Override) и сохранить расчеты, чтобы вернуться к ним позднее.
- Изменять данные в сохраненном сценарии нельзя - это просто слепок расчетов.
- Если пользователь загрузит новые данные (к примеру файл с данными о текущих продажах), то расчеты изменятся и вернуться к старым данным можно будет только через сохраненные версии.
Ставьте лайк и подписывайтесь, чтобы узнать, как эти задачи были реализованы на моем новом стэке и с какими проблемами я столкнулся, решая их.