Цифрова зрілість VARUS

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

У VARUS цей процес триває досі. Компанія поступово переводила операції в цифровий формат, перебудовувала IT-архітектуру, розвивала власні сервіси для клієнтів і співробітників. Останні два роки до цього додався ще один великий напрям – штучний інтелект. Його в компанії вже розглядають як звичайний робочий інструмент, який має допомагати швидше виконувати завдання, скорочувати зайві операції та ефективніше використовувати ресурси.

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

Сергій Плахтиря, директор ІТ департаменту мережі супермаркетів VARUS

Від окремих систем до єдиного контуру

В основі IT-ландшафту VARUS досі працює одна з найстаріших систем компанії – ERP, яка забезпечує товарні операції. Навколо неї з роками з’являлися нові сервіси. Проблема полягала в тому, що частина з них будувалася з урахуванням технологічних можливостей старої системи, а способи обміну даними поступово застарівали.

Коли у 2023 році до команди приєдналися нинішні керівники IT-напряму, одним із завдань стало об’єднати сервіси у спільний контур і спростити їхню взаємодію. Команда модернізувала протоколи комунікації між системами та продовжила рух у бік сервісної й мікросервісної архітектури.

Паралельно довелося оновлювати окремі великі системи. Один із таких проєктів – перехід зі старої системи лояльності на нову. Він охопив міграцію близько 4 млн записів і дворічної історії транзакцій: нарахування та списання бонусів та інших операцій.

Змінився і сам підхід до розробки. Зараз команда VARUS закриває всередині компанії повний цикл створення програмного забезпечення: від управління проєктами та бізнес-аналізу до розробки, тестування, інфраструктури, DevOps і технічної підтримки. Окремо сформували команду тестування, у якій працюють шість фахівців, запровадили процедури погодження, перевірки та рев’ю перед релізами.

Одним із перших напрямів, який перевели з аутсорсу всередину компанії, стала мобільна розробка. Разом із цим команда перейшла з нативних платформ на кросплатформену розробку на Flutter.

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

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

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

Один клієнт – багато сценаріїв

Технології в ритейлі особливо корисні там, де вони прибирають зайві дії з повсякденної покупки.

Комусь потрібно зайти в магазин по воду й батончик та витратити на це кілька хвилин. Для такого сценарію працює Scan&Go: товари можна відсканувати, оплатити в додатку й не ставати в чергу до каси. Інший клієнт хоче самостійно зібрати кошик і розрахуватися на касі самообслуговування. Хтось зробить замовлення на сайті та забере вже зібрані продукти в магазині. Для тих, хто взагалі не хоче витрачати час на поїздку, є доставка.

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

Цифровий досвід поступово виходить і за межі власних каналів VARUS. Інтеграції з банками дозволяють передавати електронні чеки безпосередньо в банківські додатки та використовувати ці дані в аналітиці витрат. Такі інтеграції вже працюють, зокрема, з monobank та Sense Bank.

Водночас значна частина цифровізації залишається непомітною для покупця. IT-системи працюють із процесами, які відбуваються до того, як товар чи готова страва потрапить на полицю.

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

Частину цифрових змін у ритейлі стимулює і держава. Електронні акцизні марки, електронна ТТН, електронний чек змушують бізнес перебудовувати свої системи й операційні процеси. Для IT-команди це вже частина регулярної роботи: стежити за новими вимогами та вбудовувати їх у наявну інфраструктуру.

Коли «а що, якщо?» стає частиною розробки

За останні роки український ритейл отримав досвід, який складно було б змоделювати під час звичайного стратегічного планування.

Спочатку пандемія різко збільшила роль онлайн-замовлень, доставки та мінімізації фізичних контактів. А після початку повномасштабної війни з’явилися інші запитання: як працювати без електроенергії та інтернету, як забезпечити автономність систем, що робити після пошкодження інфраструктури чи складів.

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

Що станеться, якщо зникне інтернет? Якщо під час релізу оголосять повітряну тривогу? Якщо не буде електроенергії? Якщо частина інфраструктури стане недоступною?

Відповіді на такі запитання впливають на архітектуру систем, резервування, автономність та сам процес релізу. У команді навіть з’явилося своє формулювання: зробити так, щоб “деплой із метро” не був потрібен. Зміни мають бути достатньо продуманими й контрольованими, щоб кожен реліз не запускав ланцюг термінових доробок у момент, коли умови можуть змінитися будь-коли.

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

ШІ вже всередині процесів

Наступний великий етап трансформації у VARUS пов’язують зі штучним інтелектом. Близько двох років тому компанія визначила його для себе як один із робочих інструментів і почала поступово інтегрувати в процеси.

У розробці програмного забезпечення ШІ вже застосовують на перших етапах життєвого циклу продукту: під час планування робіт, проєктування рішення й архітектури, написання та тестування коду. Контроль релізу, фінальна перевірка якості й підтримка залишаються за людьми.

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

У найближчі роки цей інструмент, імовірно, стане для ритейлу таким самим звичним, як інтернет чи мобільні додатки. Усередині VARUS до нього вже ставляться приблизно так. Хороша аналогія – екскаватор, який привезли на будівництво, де до цього землю копали лопатами. Можна й далі виконувати ту саму роботу великою кількістю людей, але новий інструмент дозволяє витрачати ресурси інакше.

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

Система, яку ми будуємо сьогодні, через два, три або п’ять років може виглядати зовсім інакше або взагалі стати непотрібною. Для команди це означає одну практичну річ: закладати можливість змін ще на етапі створення продукту. Бо технології змінюються, умови роботи змінюються, запити клієнтів теж. І здатність швидко перебудуватися дедалі більше визначає, наскільки життєздатною буде вся IT-інфраструктура ритейлу.