Retail
Система запасів для мережі міні-маркетів
Android-застосунок зі сканером у центрі для обліку, поставок і щоденних задач мережі продуктових мінімаркетів. Єдина дизайнерка: від бізнес-моделі до бети в усій мережі, з тестуванням на реальних працівниках на кожному кроці.
- Країна клієнта
- Україна
- Платформа
- Android
- Команда
- 5 людей · єдина дизайнерка
- Тривалість
- 9 місяців · 2021–2022
Огляд
Android-застосунок зі сканером у центрі для продуктової мережі міні-маркетів: запаси, поставки, щоденні задачі.
Що я вела
Єдина дизайнерка від стадії ідеї: від бізнес-моделі до живого продукту.
Дослідження
Прямий доступ до реальних працівників магазинів упродовж усього проєкту, і я користувалася ним на кожному кроці.
Результат
Реліз у бету по всій мережі: паперовий хаос у залі замінив один інструмент.
Контекст
01
Продукт
Один інструмент для працівників магазину: скануєш товар і бачиш залишки, терміни та ціни; приймаєш поставки; ведеш щоденні задачі; списання й переоцінка.
02
Користувачі
Працівники та менеджери продуктової мережі міні-маркетів. На ногах, руки зайняті, часу на меню немає, тож швидкість важливіша за функції.
Стартова точка: жодного єдиного інструмента, зате хаос із поставками, помилки в залишках, застарілі дані між менеджерами й залом.
Підхід
Змоделювати бізнес
Business Model Canvas і Service Blueprint до будь-яких екранів.
Почути зал
Опитування та інтерв'ю з працівниками, що користуватимуться щодня.
Тестувати в залі
Юзабіліті-тести на прототипах і живому продукті.
Прямий доступ до реальних користувачів від початку до кінця: кожне дизайн-рішення звірялося з торговим залом.
Процес
Ключова функціональність
01
Сканер як вхідні двері
Проблема
Щоб дізнатися залишок, термін чи ціну, працівник ішов до комп'ютера в підсобці.
Гіпотеза
Якщо все це відкривається скануванням коду просто біля полиці, відповідь займе секунди, а не похід.
Рішення
Скануєш товар і бачиш залишки, терміни придатності й ціни в одному місці. Найшвидший шлях до будь-якої відповіді в залі.
Біля полиці руки зайняті, тому вхід у все через сканер.
02
QR-вхід персоналу
Проблема
Люди переходять між магазинами, а паролі на спільних пристроях передавали з рук у руки.
Гіпотеза
Якщо вхід відбувається скануванням бейджа з вибором точки, зміна починатиметься без паролів.
Рішення
Працівники входять по QR за локацією магазину: жодних паролів біля полиці.
Жодних паролів біля полиці: досить сканувати бейдж.
03
Приймання поставки
Проблема
Поставку звіряли з накладною вручну, і розбіжності спливали вже після приймання.
Гіпотеза
Якщо сканувати товар проти початкового замовлення, невідповідність буде видно просто на прийманні.
Рішення
Поставки приймаються скануванням проти оригінального замовлення, тож розбіжності видно одразу.
Скан проти замовлення: розбіжності видно одразу на прийманні.
04
Інвентаризація
Проблема
Загальні принципи ERP та систем обліку не переносяться на мережу мінімаркетів самі собою. Більша частина роботи полягає в тому, щоб прочитати реальний процес (хто що бере в руки, у яку зміну, з чим) і підлаштувати систему під нього, а не навпаки.
Гіпотеза
Якщо система говорить мовою реальної зміни (сканувати, порахувати, замовити), персонал користуватиметься нею замість зошита.
Рішення
Графік інвентаризацій по групах товарів із прогресом і відповідальними; сам підрахунок: сканування плюс швидке введення кількості.
Інвентаризація зводиться до скана і числа, нічого більше.
05
Щоденні задачі
Проблема
Щоденні обов'язки трималися на пам'яті та усних домовленостях, і ніхто не знав, скільки зміна реально займає.
Гіпотеза
Якщо зміна є списком задач із прогресом, керівник побачить навантаження, а працівник побачить межу.
Рішення
Змінні чек-листи (відкриття, кухня, каса) з прогресом по кожній задачі та свайпами для виконання чи проблеми.
Свайп, щоб виконати, зроблений під одну руку.
06
Критичні терміни та переоцінка
Проблема
Товар із близьким терміном помічали тоді, коли лишалося тільки списати.
Гіпотеза
Якщо система заздалегідь збирає такі позиції в окремий флоу, їх устигнуть переоцінити й продати.
Рішення
Окремий флоу для товарів, що спливають, і переоцінки: терміни придатності ловляться до того, як стануть збитками.
Термін придатності ловимо до того, як він стане збитком.
07
Причини списання
Проблема
Причини списання писали своїми словами, тож порівняти магазини було неможливо.
Гіпотеза
Якщо причини задані списком, облік лишиться чистим, а дані будуть порівнюваними між точками.
Рішення
Таксономія причин списання тримає облік чистим і порівнюваним між магазинами.
Один список причин: магазини можна порівнювати.
08
Сповіщення
Проблема
Пам'ятати, що закінчується, що псується і що треба замовити, з'їдало зміну. Цю пам'ять треба було перенести в систему.
Гіпотеза
Якщо система пам'ятає залишки й терміни, зміна перестає залежати від того, хто що запам'ятав.
Рішення
Терміни, інвентаризації та замовлення приходять пушами, з фільтрами в застосунку та на лок-скріні.
Дедлайни приходять до людей, а не навпаки.
Результат
Автоматичне оновлення залишків, сповіщення про низький запас до того, як товар закінчиться, і замовлення з огляду на історію продажів.
09
Ручна синхронізація, ролі та журнал
Проблема
Мережа магазинів, ротація персоналу й кілька людей, які оновлюють залишки одночасно: дані розходилися, і ніхто не знав, чия версія правильна.
Гіпотеза
Якщо синхронізація явна, а кожна зміна записана, розбіжність стає видимою й виправною, а не предметом суперечки.
Рішення
Кнопка ручної синхронізації виправляє розбіжності даних між менеджером і залом; ролі та журнал дій роблять зміни підзвітними.
Коли дані розходяться, один тап синхронізує, і це логується.
Що змінили тести з працівниками магазинів
Залишки в базі не збігалися з полицею, бо магазини оновлювались у різних циклах.
Синхронізація на вимогу: один дотик, і менеджер бачить те саме, що й зала.
Помилки ручного вводу: людський фактор давав найбільше хибних даних.
Скан коду замість набору, підказки та перевірки у формах.
Дублі й загублені записи, коли кілька людей оновлювали дані одночасно.
Структурований порядок оновлення й лог змін: хто, що і коли змінив.
10
Спроєктовано й у розробці
Ще чотири частини системи були спроєктовані й передані в розробку, поки застосунок виходив у бету.
Нотатка
Запити із залу не закінчувались; ці чотири були наступними, що варті розробки.
Ключові рішення
01
Сканер у центрі за задумом
Проблема
Працівникам потрібні відповіді біля полиці (залишки, термін, ціна), а будь-який шлях через меню був заповільним із зайнятими руками.
Гіпотеза
Якщо сканер стане вхідними дверима, працівник із зайнятими руками дійде до будь-якої відповіді швидше, ніж через будь-яке меню.
Рішення
Зробила сканер вхідними дверима застосунку: сканування товару відкриває все про нього (залишки, терміни, ціни та наступні дії).
Підтвердження
Юзабіліті-сесії на живому продукті: «сканувати й отримати відповідь» стало типовим способом користування застосунком.
03
Чесне рішення для застарілих даних
Проблема
Дані застарівали між менеджерами й залом: цифри в телефоні не збігалися з полицею.
Рішення
Додала кнопку ручної синхронізації для миттєвого звіряння, підкріплену ролями та журналом дій: кожна зміна підзвітна.
Підтвердження
Вийшло в бету по всій мережі: скарги на розбіжності, з яких усе почалося, і були брифом цієї фічі.
Результат
- Реліз у бету по всій мережі
- Швидший облік товарів у залі
- Поставки звіряються з оригінальними замовленнями
- Терміни придатності ловляться до того, як стануть збитками
Паперовий хаос став одним інструментом зі сканером у центрі, який працівники справді тримають у руці.
Наступний кейс
Платформа портфеля private equity
Жива, відзначена нагородами платформа value creation для PE-фондів. Моя частина: конструктор дашбордів із віджетами на сітці з двох ширин, режимами Edit і View і бордом, який живе далі в PowerPoint.
Переглянути кейс