Модулі MySales

Впровадження MySalesМожливості

Процес впровадження MySales можна технічно розділити на такі етапи:

94%
Точність прогнозу

Точність для постійного асортименту в Drogas

15-20%
Зростання доходів

Зростання обороту в Chudo Market після впровадження

40%
Зменшення втрат

Скорочення списань свіжих продуктів у Blyzenko

Платформа ШІ

Єдина платформа ШІ поєднує прогнозування, поповнення, ціноутворення та промо — сигнали передаються автоматично між модулями, тому замовлення, ціни та кампанії завжди синхронізовані.

Аналітика

Підготовка сховища та історичних даних Завантаження історичних даних промо Навчання на даних промо Тестування та перевірка прогнозів Налаштування постійної інтеграції Налаштування та запуск авто-замовлення для пілотної групи Розгортання авто-замовлення для всіх інших груп Часові рамки впровадження дуже залежать від специфіки потреб клієнта та обсягу запланованих робіт.

Так, якщо впроваджується лише базовий модуль, це може бути зроблено за місяць, але якщо підключаються всі інші модулі, то приблизна оцінка часу впровадження розраховується індивідуально для кожного клієнта.

Цей вступний посібник описує всі етапи впровадження MySales за умови підключення всіх модулів.

Якщо клієнт підключає лише частину модулів, процес впровадження відрізнятиметься лише часом виконання та меншою кількістю необхідних операцій.

Логіка залишиться незмінною. Нижче детальніше розглянуті всі етапи процесу впровадження системи MySales.

Підготовка даних — це перший і, мабуть, найважливіший етап у процесі впровадження.

На цьому етапі клієнт підготовлює всі необхідні історичні дані, готує сервер і базу даних та надає їх команді впровадження MySales для перевірки.

Як правило, дані підготовлює ІТ-команда клієнта відповідно до специфікації, наданої MySales.

Для цього в СУБД клієнта створюється сховище даних, де команда впровадження створює необхідну структуру таблиць.

Для СУБД виділяється апаратний/хмарний ресурс, а для встановлення програмного забезпечення MySales — апаратний/хмарний сервер.

Технічні вимоги до сервера та бази даних визначаються під час узгодження проекту і можуть відрізнятися залежно від встановлених модулів та обсягу даних (кількості комбінацій SKU/магазин).

Далі ІТ-команда клієнта завантажує дані до цієї бази даних відповідно до специфікації.

Дані завантажуються з існуючої системи клієнта або кількох систем, де зберігається така інформація.

У рамках цього етапу підготовлюються такі дані: Довідник товарів та товарних груп Довідник магазинів та регіонів Історія продажів в обсязі та вартості, залишки, надходження та списання, по тижнях за останні 3 роки Історія продажів в обсязі та вартості, залишки, надходження та списання, по днях за останній рік Історія роздрібних цін Останні закупівельні ціни, якщо планується використання функціональності модуля ціноутворення Штрих-коди товарів, якщо планується використання функціональності модуля ціноутворення Вся необхідна інформація для підготовки даних для цих двох модулів надається у спеціально створеному файлі MySales.

У ньому описані всі таблиці, які необхідно створити в підготовленій базі даних, детальний опис кожного поля, необхідна частота оновлення цих даних, а також запити для оновлення бази даних, створеної для MySales, щоб спростити роботу ІТ-команди клієнта.

Оскільки дані повинні постійно оновлюватися, ІТ-команді клієнта рекомендується налаштувати їх автоматичне оновлення для таблиць, зазначених у файлі, ще на етапі завантаження даних до бази MySales.

Для найефективнішої роботи системи рекомендується завантажувати дані про продажі за останні три роки.

Файл специфікації для підготовки даних можна знайти за посиланням .

Усі підготовлені дані повинні бути перевірені та затверджені командою MySales.

У рамках цього етапу клієнт підготовлює історичні дані промо для завантаження в MySales.

Щонайменше рекомендується завантажувати історію промо за останній рік, але 2–3 роки є більш кращим варіантом.

Необхідно підготувати таку інформацію: Дата початку та дата закінчення промо Перелік промо-позицій Перелік промо-магазинів Тип промо (TPR — тимчасове зниження ціни, MMK — знижка, що надається на касі) Тип механіки для промо типу MMK (1+1=3, купи 1 і отримай знижку на другий товар тощо) Розмір знижки для всієї акції у відсотках або індивідуальна знижка для кожної позиції Також рекомендується вказати звичайну роздрібну ціну; однак якщо ця інформація може бути заповнена автоматично на основі історії, це можна не робити.

Вся необхідна інформація для підготовки даних для модуля Промо надається у спеціально створеному файлі MySales.

На відміну від базового модуля, у випадку промо клієнт підготовлює лише історичні дані промо у форматі файлу Excel.

Налаштування бази даних та завантаження необхідних промо-даних у систему виконується командою впровадження MySales.

Файл специфікації для підготовки промо-даних можна знайти за посиланням .

Після заповнення всіх таблиць, описаних у файлі, командою MySales проводиться перевірка отриманих даних; якщо знайдені помилки, команда впровадження повідомляє про них клієнта та просить їх виправити.

Ключова мета цього етапу — виконати найоптимальніші налаштування системи для прогнозування промо, а також перерахувати всі промо в історії та навчити алгоритм прогнозування зростання промо.

Як правило, цей процес має ітераційний характер і починається після завантаження всіх історичних промо в систему: Налаштування системних параметрів для прогнозування промо Перерахунок усіх промо в історії Навчання алгоритму Тестування прогнозів та аналіз точності прогнозів промо Повторення попередніх ітерацій для покращення результатів прогнозування Для початку використання системи, як правило, достатньо 3 ітерацій; однак більш детальне налаштування може бути виконано пізніше.

Тестування та перевірка прогнозів — це процес безперервного вдосконалення.

У рамках проекту завжди рекомендується тестувати як звичайні, так і промо-прогнози.

Рекомендується тестувати прогнози на рівні SKU–всі магазини–тиждень, щоб скоротити трудовитрати, які зростають у рази при переході на рівень SKU–магазин–тиждень.

Для максимальної прозорості під час впровадження ми перевіряємо якість прогнозів, побудованих нашим клієнтом, та прогнозів, побудованих за допомогою MySales.

Загалом методологія порівняння прогнозів така: Клієнт готує свої прогнози на рівні SKU–всі магазини–тиждень для наступного тижня або більшого проміжку часу та завантажує їх у файл MySales також будує прогнози за аналогічний період часу та завантажує прогнози того самого рівня у файл Клієнт та MySales обмінюються запароленими архівами з результатами прогнозів Через деякий час паролі розкриваються, і ми аналізуємо точність прогнозу, порівнюючи його з реальними продажами Цей етап дуже важливий для стабільної роботи MySales у зв'язці з системою клієнта в майбутньому.

При налаштуванні постійної інтеграції варто виділити 2 основних блоки: Інтеграція для базового модуля Інтеграція для авто-замовлення Інтеграція базового модуля включає регулярне оновлення та доповнення таких даних: Довідник товарів та товарних груп Довідник магазинів та регіонів Історія продажів в обсязі та вартості, залишки, надходження та списання, по тижнях за останні 3 роки Історія продажів в обсязі та вартості, залишки, надходження та списання, по днях за останній рік Історія роздрібних цін Останні закупівельні ціни, якщо планується використання функціональності модуля ціноутворення Штрих-коди товарів, якщо планується використання функціональності модуля ціноутворення Інтеграція авто-замовлення включає регулярне оновлення та доповнення таких даних: Довідник постачальників та контрактів Презентаційний запас Кількість в упаковці для магазинів і складів, мінімальне замовлення (можливо як варіант передачі з MySales до системи клієнта, так і із системи клієнта до MySales) Прив'язки джерел замовлення для кожної комбінації SKU/магазин та SKU/склад, пов'язаних із постачальником та контрактом Останні залишки для магазину та складу Надходження товарів за замовленнями магазинів і складів Після завершення всіх попередніх кроків наступним кроком є налаштування схем для пілотної групи товарів та замовлення їх за допомогою авто-замовлення MySales.

Важливо, щоб перехід здійснювався саме групу за групою для всіх магазинів, а не магазин за магазином для широкого асортименту товарних груп.

Адже необхідно перевірити параметри замовлення, включаючи кількість в упаковці, мінімальні кількості замовлення, презентаційний запас, а також прив'язки до постачальників/контрактів.

Щоб почати замовляти першу групу за допомогою авто-замовлення MySales, необхідно також запланувати запуск пакетної обробки для перерахунку замовлень.

Після виконання цих кроків потрібно перевірити коректність автоматичного вивантаження замовлень із MySales до системи клієнта, а також чи були вони відправлені електронною поштою/EDI.

Також важливо перевірити, що надходження коректно завантажуються в MySales.

Спочатку рекомендується перевіряти всі замовлення для пілотної групи і, якщо є зауваження, коригувати параметри схем.

Також важливо аналізувати страховий запас і керувати коефіцієнтами страхового запасу на рівні SKU–всі магазини та додавати аналоги для нових позицій і нових магазинів.

Після успішного тестування пілотної групи та налагодження процесу автоматичного замовлення залишається лише підключати дедалі більше груп до автоматичного замовлення MySales.

Для цього достатньо налаштувати нові схеми та перевірити замовлення, створені вперше, щоб скоригувати параметри схеми та коефіцієнти страхового запасу.

А також не забути вказати аналоги для нових магазинів/товарів.