Олена Фастовець-Омельченко поділилася досвідом роботи бізнес-аналітика на проєкті відкриття першого офлайн-флагмана для вже наявного e-commerce-ритейлера. Як вибудувати єдину омніканальну екосистему, де інтернет-магазин і фізична точка продажу живуть за одними правилами цін, залишків і замовлень — читайте далі.
1. Контекст і бізнес-ціль
Онлайн-магазин до моменту запуску офлайн-флагмана вже мав сформований асортимент, процеси онлайн-замовлення та власну логіку роботи зі складами й цінами, зав’язаними на e-commerce-платформу. Бізнес хотів зробити наступний крок і відкрити фізичну точку продажу, яка не буде жити «своїм життям», а працюватиме як продовження онлайн-каналу: з тими ж SKU, акціями, правилами цін і залишків, синхронізованими між сайтом і офлайн-магазином. Це вимагало побудови єдиної моделі даних по складах, каналах продажів і офлайн-точках, а також прозорої зв’язки між ними через API та серію методів по цінах.
Ключова бізнес-ціль полягала в тому, щоб продавець у магазині працював у тому ж інформаційному полі, що й клієнт на сайті: бачив актуальні залишки по складах, фінальні роздрібні ціни з урахуванням промо, міг коректно оформити продаж чи резерв, а система — зафіксувати це як частину єдиної омніканальної історії замовлень. Для цього було заплановано створити окреме автоматизоване робоче місце продавця-консультанта (АРМ-ПК) з чіткими бізнес-сценаріями (від підбору товару до друку цінника), інтегрувати його з бекенд-API і налаштувати процеси управління цінниками та SKU так, щоб будь-яка зміна в централізованій ціновій матриці та stock-даних коректно відображалась як офлайн, так і онлайн.
2. Область застосування і роль BA
У цьому проєкті зона відповідальності не обмежувалася описом окремого екрана або однієї бізнес-функції. Завдання було ширшим: розкласти весь ланцюжок роботи нового офлайн-магазину на зрозумілі процеси, узгодити їх із тим, як уже працював інтернет-магазин, і звести все в єдину логіку для команди розробки, операційки та суміжних учасників. На практиці це означало роботу з процесами продажу, пошуку товару, оформлення замовлення, відображення залишків, синхронізації цін, друку цінників і передачі даних у зовнішні системи. Роль BA зводилася до того, щоб зв’язати бізнес-логіку, технічну реалізацію і реальний сценарій роботи в торговій точці в одну узгоджену систему.
Зверни увагу: За межами основ БА: комплексний погляд на потреби, вимоги та рішення
2.1 Які саме задачі потрапили в зону відповідальності
У межах цього проєкту відповідальність охоплювала не одну окрему функцію, а весь ланцюжок, який мав зв’язати офлайн-магазин із наявною e-commerce-інфраструктурою. Потрібно було описати процеси так, щоб команда могла реалізувати повноцінний сценарій роботи продавця: пошук товару, перегляд доступності, формування продажу, роботу з цінами, друк цінників і передачу даних у пов’язані системи. Окремий фокус був на тому, щоб офлайн-операції не існували окремо від онлайн-даних, а спиралися на єдину систему залишків, SKU, цін і промо.
Крім процесів, у зону відповідальності входили дані та їх узгодження між різними частинами системи. Треба було розібрати, які саме сутності потрібні для офлайн-магазину, як вони співвідносяться зі складськими даними, як передавати актуальні ціни та як відображати зміни без втрати цілісності сценарію. Значна частина роботи стосувалася інтеграцій: потрібно було зафіксувати, звідки беруться дані, куди вони передаються і що має відбуватися у разі розбіжностей або неповної інформації. До цього додавалися нефункціональні вимоги: зрозумілий інтерфейс для продавця, достатня швидкість відгуку системи, стабільна робота в робочому середовищі та передбачувана поведінка системи в критичних точках.
2.2 З якими стейкхолдерами довелося працювати
У проєкті було кілька груп стейкхолдерів, і кожна впливала на свій шматок рішення. З операційною командою узгоджувалося, як саме виглядатиме щоденна робота магазину: що робить продавець у типовому сценарії, як він діє у разі нестачі даних, як оформлює продаж і що має бачити на екрані в складних випадках. Ця команда надавала багато практичного контексту, без якого рішення залишилося б надто теоретичним і відірваним від реальної роботи магазину.
З категорійним менеджментом та маркетингом обговорювали логіку цін, акцій і відображення промо, бо офлайн-точка мала працювати в тій самій комерційній рамці, що й інтернет-магазин. З внутрішньою та зовнішньою ІТ-командою розбирали структуру майбутнього рішення, інтеграції, обмін даними, сценарії помилок і те, як це все має виглядати в інтерфейсі та на рівні бекенду. Роль BA у цій взаємодії — перекласти різні мови: бізнесу, операцій, техніки й зовнішніх виконавців — в одну зрозумілу специфікацію, де кожен учасник бачить свою частину, але всі частини складаються в один робочий процес.
3. ІТ-ландшафт та інтеграції
Офлайн-магазин не будували як окрему систему з нуля. Його вбудовували в уже наявний e-commerce-ландшафт, де частина даних жила в бекенді інтернет-магазину, а інша частина — в окремій обліковій системі, а новий офлайн-канал мав стати ще однією точкою доступу до тієї ж самої товарної логіки. Для аналітика це означало, що будь-яке рішення потрібно було розглядати не лише в межах одного модуля, а й в контексті всього ланцюжка: від появи товару в системі до його відображення в магазині, на ціннику, у кошику продавця та в підсумковому чеку.
3.1 Проєктування АРМ продавця-консультанта: перенесення кошика в офлайн
Автоматизоване робоче місце продавця-консультанта (АРМ-ПК) стало центральною точкою всієї офлайн-моделі, оскільки саме через нього електронна логіка інтернет-магазину переходила у фізичний сценарій продажу. Якщо в онлайні клієнт самостійно шукає товар, додає його в кошик і приймає рішення, то в магазині цю саму послідовність виконує продавець, ще й у прямій взаємодії з покупцем. Через це інтерфейс не можна було повністю «запозичити» із сайту. Потрібно було переосмислити його під інший темп роботи: швидкий пошук, мінімум зайвих дій, зрозумілі статуси товару і чітка реакція системи в момент, коли продавець уже стоїть перед клієнтом і не має часу розбиратися, чому щось не спрацювало.
Критичним для проєкту був базовий сценарій продавця: знайти товар, перевірити його доступність, додати до кошика і перейти до оформлення без розриву між кроками. Саме цей ланцюжок визначав, чи буде система зручною в реальній роботі магазину. Тому в аналізі важливо було не просто описати поля й кнопки, а зафіксувати стани інтерфейсу, логіку переходів і правила для ситуацій, коли система не може віддати ідеальний результат.
3.2 Архітектура даних: як бекенд інтернет-магазину став базою для офлайну
Щоб офлайн-магазин працював коректно, йому потрібна була не окрема товарна база, а доступ до вже сформованої інфраструктури даних. Саме тому в основі рішення лежала синхронізація з бекендом інтернет-магазину, де зберігалися дані про товари, залишки, склади, типи точок і цінову інформацію. Для офлайн-каналу було важливо не просто отримати дані, а правильно інтерпретувати їх у контексті фізичної точки продажу.
Окремий шар роботи стосувався цін і доступності. У специфікаціях API закладено механіку, яка дозволяє отримувати актуальні значення для конкретних складів і магазину, бачити зміну ціни через звіти, відображати доступність товару з урахуванням цін, залишків і доступних складів та синхронізувати ці дані з конкретною точкою продажу. Для аналітика тут головне — визначити, які поля є критичними для офлайн-сценарію, як часто ці дані оновлювати, що робити, якщо частина інформації відрізняється між джерелами, і як не допустити розриву між тим, що бачить продавець, онлайн-клієнт і тим, що реально лежить у системі.
Буде цікаво: HTTP статус-коди. Огляд для бізнес-аналітика
3.3 Фізичний вимір даних: цінники, QR-коди та промо
Один із найцікавіших моментів у переході з онлайну в офлайн полягає в тому, що цифрові дані починають жити у фізичних носіях. У цьому проєкті таким носієм став цінник — невеликий елемент, який насправді концентрує в собі багато логіки: SKU, назву товару, вартість, візуальні позначки, промо-атрибути й QR-код як місток між полицею та цифровим середовищем. Для аналізу це був окремий пласт задач: тут уже недостатньо просто отримати правильне значення з системи. Потрібно було зрозуміти, як ці дані відображатимуться в залі, хто і коли їх друкує, які поля є обов’язковими, а які — допоміжними, і що саме допомагає продавцю або покупцю швидко ідентифікувати потрібну позицію.
Саме в цьому блоці проявилася ще одна практична дилема: ціна в системі може змінюватися швидше, ніж оновлюється фізичний цінник у магазині. Проблема полягала не лише в синхронізації, а в тому, яке значення вважати пріоритетним у момент продажу, щоб АРМ продавця, паперовий цінник і чек не суперечили один одному. Це не технічне питання формату даних, а питання правил бізнесу і поведінки системи в реальному середовищі.
3.4 Чекаут та інтеграція оплат
Фінальний етап офлайн-сценарію — чекаут — замикав увесь попередній ланцюжок: коректність товарних даних, наявність, фінальну ціну, обраний сценарій продажу та передачу результату в суміжні системи. На цьому етапі АРМ-ПК уже не просто допомагав продавцю зібрати кошик, а ставав точкою, де система мала підтвердити, що всі попередні частини процесу узгоджені між собою. Якщо на чекауті виявлялася розбіжність у ціні, недоступність товару для конкретної точки або проблема з оплатою, це означало, що помилка виникла не в одному екрані, а на стику кількох бізнес-правил.
Для аналізу важливо було описати не лише успішний сценарій, а й те, що відбувається, якщо транзакція переривається, підтвердження не надходить або операція потребує додаткового кроку. Чекаут у такій системі треба розглядати як координуючий вузол, де сходяться інтерфейс продавця, товарна логіка, фінальні значення з бекенду та зовнішня платіжна взаємодія.
4. Граблі і «якби робили вдруге»
4.1 Прогалини в аналізі
Перший компроміс був пов’язаний із масштабом і часом. На підготовку було всього три місяці, тому команда свідомо сфокусувалася на найважливіших сценаріях і запустила MVP лише для одного магазину. Через це частина рішень закладалася як тимчасова: без повної універсальності, без розширеної моделі ролей і без можливості легко масштабувати АРМ під інші точки продажу та точки видачі.
Друга прогалина стосувалася керування екосистемою магазинів і доступів. У першій версії не було повноцінного адміністративного контуру, де адміністратор сайту міг би самостійно створювати нові магазини, точки видачі та налаштовувати права доступу. Цю частину свідомо відклали на наступний етап, але в аналізі це означало, що частина майбутніх сценаріїв не була деталізована одразу.
Третя зона ризику — в MVP зазвичай добре описуються основні потоки, але гірше — рідкісні або складні винятки. Для офлайн-ритейлу це особливо чутливо: часткові сценарії, помилки синхронізації, нетипові варіанти роботи з доступністю товару, розбіжності між даними в системі та фактичною ситуацією в магазині.
4.2 Lessons learned для BA
Головний висновок із такого формату роботи — у короткому MVP не можна обмежуватися лише тим, що «потрібно зараз». Навіть якщо команда запускає одну точку, варто одразу фіксувати, як це рішення масштабуватиметься далі: які сутності мають бути універсальними, де потрібна гнучка модель ролей, як адмініструються магазини, хто і як керує доступами. Інакше пілот працює, але наступний крок вимагає майже нового аналізу.
Другий важливий урок — не відкладати моделювання адміністративних і виняткових сценаріїв «на потім» без хоча б базового каркаса. Якщо в першій версії не закласти логіку створення магазинів, ролей і прав доступу, то згодом це стає не просто додатковою фічею, а окремим великим проєктом. Краще хоча б зафіксувати їх як майбутні правила, ніж залишити повністю поза моделлю.
Третій висновок — у таких проєктах корисно одразу домовлятися про рівень деталізації для кожного блоку. У MVP можна спростити інтерфейс, відкласти частину автоматизації та вручну обробляти деякі процеси, але ці спрощення мають бути явно задокументовані. Саме тому в подібних кейсах аналітик має не лише збирати вимоги, а й позначати, які частини моделі є стабільними, а які потрібно буде переробити після першого запуску.
До теми: 6 практик, які повинен виконувати кожен бізнес-аналітик
5. Що вдалося на етапі MVP?
У межах першої ітерації вдалося запустити базовий, але цілісний контур роботи для одного офлайн-магазину. Команда реалізувала АРМ продавця як єдине робоче місце для ключових операцій у залі, підключила його до товарних і цінових даних, забезпечила роботу з цінниками та закрила основний сценарій продажу від пошуку товару до оформлення покупки. Для MVP цього було достатньо: магазин не працював як ізольована точка, а одразу вбудовувався в існуючу логіку e-commerce.
Найважливіше, що в першому запуску реально запрацював саме зв’язок між каналами. Продавці отримали інструмент, який спирався на ту саму товарну модель, що й онлайн-магазин, а бізнес — перший практичний варіант офлайн-точки без розриву в базовій логіці цін, залишків і продажу. Це не була завершена екосистема в остаточному вигляді, але перший магазин вдалося запустити в межах запланованого етапу — а отже команда отримала не тільки MVP, а й основу для подальшого масштабування рішення.
Висновки: специфіка аналізу для омніканального ритейлу
Омніканальний ритейл змінює саму природу бізнес-аналізу. Тут уже недостатньо описати окремий процес продажу або один інтерфейс — потрібно побачити, як клієнтський сценарій проходить через кілька каналів, як між ними рухаються дані, і де саме система може дати збій. У таких проєктах BA працює не тільки з вимогами до функціоналу, а й з узгодженням логіки між онлайн-каналом, офлайном, складом, оплатою, цінниками, ролями та внутрішніми процесами магазину.
Головна складність полягає в тому, що кожен канал має свою швидкість, свої обмеження й свою точку болю. Онлайн часто живе в логіці зручності та швидкого доступу до даних, офлайн — у логіці операційної дисципліни, фізичних дій і миттєвих рішень на місці. Завдання BA — зібрати це в одну модель, де дані не суперечать одне одному, а сценарії не розпадаються на окремі шматки залежно від каналу.
Ще одна важлива риса омніканального аналізу — потреба мислити на кілька кроків уперед. MVP може закривати один магазин і базовий набір сценаріїв, але вже на етапі першої реалізації потрібно закладати основу для масштабування: нові точки, ролі, доступи, адміністрування, зміни в моделі даних. Якщо цього не зробити, перший запуск буде успішним лише локально, а наступна ітерація перетвориться на перепроєктування. Для BA це означає, що якісний аналіз у ритейлі — це не тільки точність у теперішньому моменті, а й здатність побачити, як рішення житиме після запуску.
Також до теми: Як бізнес-аналітикам переконувати за допомогою сторітелінгу