В первой версии статьи я много написал про устройство системы, а про её пользу рассказал вскользь. В комментариях закономерно спросили, зачем понадобилась вся эта разработка и что клиент получил за свои деньги. Переписал текст с учётом этих вопросов и опыта, который появился после запуска.
На момент проекта у Simple Coffee было 26 кофеен и больше 240 тысяч чеков в месяц. Сеть работала в Екатеринбурге уже больше десяти лет. Продажи учитывались в R-Keeper, управленческие отчёты собирали в Excel.
В каждом чеке есть подробности, которые теряются в общей выручке: состав заказа, скидка, время покупки, конкретная кофейня. Для управляющего сетью это полезный материал. Можно сравнивать ассортимент, смотреть, как отличаются утренние и вечерние продажи, разбирать экономику отдельных позиций.
Но сначала всё это надо собрать так, чтобы результатам сравнения можно было верить.
Заказчик хотел получать отчётность ежедневно и разбирать показатели вплоть до отдельного чека. Если у одной кофейни изменился средний чек, нужно было понять, что произошло с продажами: изменилось количество товаров в заказе, покупатели стали выбирать другие позиции, выросла доля скидок? В месячном отчёте отклонение тоже будет видно. Только к тому времени оно уже несколько недель будет влиять на результат.
Здесь я неудачно сформулировал мысль в первой версии: написал так, будто 240 тысяч чеков сами по себе делают Excel непригодным. Конечно, это не так. Объём ещё ничего не говорит о том, какой инструмент нужен бизнесу. Считать в Excel можно много чего.
В нашем случае требовалось ежедневно получать данные, приводить их к общим правилам и давать сотрудникам возможность самостоятельно разбирать продажи. При этом одинаковые товары в разных кофейнях должны были попадать в одинаковые категории. Вот с этим оказалось интереснее, чем с выбором инструмента.
Сначала пришлось разобраться с товарами
Мы в Smart Easy BI подключились к R-Keeper через собственный коннектор по API. Забирали транзакции, позиции чеков, скидки и модификаторы. Настроили ежедневную загрузку, хранение и обработку данных в ClickHouse, отчёты собрали в DataLens.
В исторических данных один товар мог быть заведён по-разному в разных точках. Категоризация тоже различалась. Для кассы это не обязательно мешает работе: товар можно выбрать, продать и пробить чек. Трудности начинаются при сравнении кофеен.
Допустим, вы смотрите продажи категории за месяц. Если часть товаров в другой точке отнесена к соседней категории, на графике получится разница. Только объяснять её предпочтениями гостей рано: сначала надо проверить, одинаково ли мы вообще сгруппировали товары.
Это и обнаружилось при подготовке данных. Нам пришлось выровнять общий каталог товаров, категорий и подкатегорий, настроить соответствия между исходными записями и добавить проверки при загрузке.
Я бы сейчас уделил этому месту в статье больше внимания. По скриншотам такую работу почти не видно. Но если её пропустить, дальше люди будут обсуждать продажи и принимать решения на основании разницы, которую сами же создали в справочниках.
Обработка была устроена достаточно обычно: сохраняли исходные данные, отдельно приводили их к единому виду, затем готовили таблицы для отчётов по точкам, ассортименту, скидкам и времени продаж. Повторная загрузка не должна была создавать дубли, а итоговые показатели нужно было сверять с источником.
Поэтому на вопрос из комментариев «почему нельзя было просто подключить BI к кассовой системе?» ответ в этом проекте такой: подключение давало доступ к записям, но оставалась работа с их содержанием. Разницу в товарных справочниках BI-система сама не исправит. Правила сопоставления всё равно придётся определить.
Что получилось в отчётах
На проект ушло около трёх месяцев. В результате у команды появились ежедневные отчёты по сети с детализацией по кофейням, товарам, скидкам и чекам.
Ниже — те же экраны, что были в первой версии статьи. Данные обезличены, структура и логика соответствуют рабочему решению. Цифры на скриншотах иллюстрируют возможности отчётов.
Как сеть использует эту аналитику
Уже в первые месяцы проекта данные использовали для корректировки меню и рекламы. Позже в обратной связи от клиента появился ещё один существенный момент: стало проще готовить аргументы для новых предложений.
Например, перед вводом сезонного напитка можно посмотреть, как раньше продавались похожие позиции: в каких кофейнях, в какое время, по какой цене. Это не предскажет результат нового запуска. Зато у команды есть история продаж, с которой можно сверить своё предположение.
Раньше для такой проверки приходилось поднимать Excel-файлы и отдельно готовить расчёты. Теперь нужные срезы доступны в системе. На масштабе сети это заметное изменение в повседневной работе: предложение по меню можно предметно обсудить до запуска, а после — проверить, что получилось.
В первой версии я назвал статью «Как мы нашли утекающую маржу». Заголовок получился сильнее доказательств, которые я привёл. Читатель вправе ждать под ним конкретную находку, сумму потерь и результат исправления. Галерея дашбордов на этот вопрос не отвечает.
Поэтому я изменил заголовок. В этом кейсе я могу показать, как мы организовали ежедневную аналитику, с какой проблемой столкнулись в данных и для каких решений сеть использует результат. Расчёт окупаемости потребовал бы отдельно разобрать стоимость разработки и поддержки, изменения в работе кофеен и их вклад в прибыль. Подменять такой расчёт словами «стало эффективнее» не хочется.
Для меня главный результат проекта виден в обратной связи от клиента: команда использует систему, когда обсуждает меню, рекламу и дальнейшее развитие сети. Появились запросы на расширение аналитики по другим функциям компании. Это уже опыт работы после внедрения — и о нём стоило рассказать подробнее с самого начала.
