От решения к отчету, а не наоборот
Кирилл Колышкин начинает с распространенной ошибки: компания собирает таблицу из доступных столбцов, а затем пытается придумать, какое управленческое решение эта таблица поддерживает. Такой отчет может быть аккуратным и при этом бесполезным. Начинать нужно с вопроса: какое решение мы должны принять, с какой частотой, кто за него отвечает и по каким данным увидим результат? После этого определяются состав полей, период, единица анализа и правила проверки данных.
В марке это может быть решение о дозакупке, изменении цены, маркетинговой поддержке изделия, перераспределении остатка между каналами или пересмотре плана следующей коллекции. Одной цифры «продажи» для этих решений недостаточно. Заказ, отгрузка, выкуп, возврат и поступление денег происходят в разные даты. Если смешать их в одном показателе, отчет будет меняться не только из-за работы команды, но и из-за скрытых правил учета.
Когда произошла продажа и чей это возврат
Интернет-заказ может быть отгружен через несколько часов или дней, а возврат прийти существенно позже. Для оценки операционной нагрузки полезна дата заказа, для оценки движения товара — дата отгрузки, для денежных потоков — дата платежа или возврата. Выбор даты нельзя делать незаметно внутри формулы: в отчете должно быть понятно, какой именно процесс показывает период.
Отдельная задача — отнести возврат к каналу. Покупатель мог приобрести изделие онлайн, а вернуть в розничном магазине. Для финансовой ответственности за продажу логично смотреть на исходный канал; для движения денег и нагрузки точки приемки нужен канал возврата. Это разные вопросы, и под них могут существовать разные представления одних событий. Если возвраты по сезону приходят с задержкой, текущую неделю нельзя сравнивать с прошлой как окончательно закрытую: поздние возвраты еще изменят ее результат.
Остаток не равен доступности
Товар, который движется между складами, может не входить в обычный отчет остатков, хотя он уже принадлежит компании. Товар в резерве физически лежит на складе, но его нельзя одновременно обещать другому покупателю. При этом разные резервы могут иметь разную природу: под интернет-заказ, под пополнение магазина или под другой канал. Формальное суммирование резервов скрывает эту разницу.
Колышкин показывает, что для решения о продаже и дозакупке нужен не абстрактный остаток, а явно заданная категория доступности: где изделие находится, может ли оно быть продано сейчас, за кем зарезервировано и когда снова станет доступным. Товар на приемке, в ОТК, на утюжке или в пути тоже влияет на срок выхода коллекции, хотя в витрине готовых к продаже единиц его может не быть. Поэтому операционная модель и аналитическая витрина должны иметь понятное соответствие, иначе продавец и продуктовая команда смотрят на разные «правды».
Одна единица изделия во всех таблицах
Отчет легко задваивает продажи, если соединить таблицу остатков с таблицей каналов или несколькими штрихкодами одной модели без проверки ключа. В лекции разобраны сочетания номенклатуры и характеристики, артикула, размера, штрихкода и внутреннего ID. Универсального поля для всех компаний нет. Нужно описать, что именно является единицей анализа: модель, цвет, размер, SKU или физическое изделие, и не соединять таблицы с разной гранулярностью как будто их строки обозначают одно и то же.
Практический способ — держать справочник изделий и журнал событий отдельно от итоговых сводок. В журнале каждое событие имеет дату, идентификатор изделия, тип движения, канал и количество; правила преобразования в управленческие показатели описаны отдельно. Сводная таблица или дашборд строятся поверх этого слоя. Автоматическая формула не освобождает от контроля: нужно проверять количество строк, дубли идентификаторов и несоответствия между суммой событий и показателем на экране. В лекции есть примеры в таблицах и 1С, но сама методика не привязана к одному инструменту.
Цена, план и причина отклонения
Цена не всегда есть у изделия, которого сейчас нет в остатке или которое продается в другом канале. Если аналитика берет цену только из текущего складского отчета, возврат или новая поставка могут показать неожиданное расхождение цен между размерами. Значит, цену и историю ее изменения следует учитывать отдельно от наличия товара. Аналогично продажи в штуках и деньгах дают разные картины при скидках: рост количества может сопровождаться падением выручки на единицу.
План должен иметь ту же временную детализацию, в которой принимается решение. Если команда пересматривает действия каждую неделю, одного месячного плана недостаточно для честного недельного план-факта. При отклонении полезно записывать не только число, но и проверенную причину: поздний запуск, нехватка товара, иной спрос, изменение цены, задержка в логистике или ошибка учета. Вслед за причиной пишут действие, ответственного и дату повторной проверки. Иначе отчет каждый раз объясняет прошлое, но не улучшает следующую итерацию.
Колышкин предлагает не подменять решения о новых моделях математическим прогнозом без достаточной истории. Базовые повторяющиеся изделия можно оценивать по накопленным продажам, а запуск нового изделия часто требует экспертного плана. Затем фактические события уточняют исходную гипотезу. Это не спор «человек или формула»: человеку нужны хорошие данные, а формуле — достаточное основание.
Итоговый отчет как память решения
Хороший итоговый отчет позволяет восстановить: что планировали, что произошло, какие данные считались надежными, почему возникло отклонение и какое решение приняли. Его ценность возрастает, когда он связан с календарем разработки, производства и поставки: фактическая дата выхода изделия в продажу тогда объясняет часть коммерческого результата. Следующий сезон начинается не с чистого листа, а с проверенной истории изделия и действий команды.
