https://primeeva.com/
Кейс Польський Завод ПраймЕВА
Prime EVA це польське виробництво автомобільних килимків з EVA-матеріалу, входить до Evaline Group. Килимки робляться під конкретну машину: марку, модель, покоління, кузов і коробку передач. Покупець сам обирає фактуру, колір килимка та колір окантовки, комплект (лише передні, повний набір, багажник тощо), а завод виготовляє виріб під замовлення і відправляє його по Європі. Магазин працює англійською, німецькою та польською.
Ззовні це охайний інтернет-магазин. Усередині кожне замовлення це маленький виробничий проєкт: прийняти, підібрати лекала під модель авто, запустити у виробництво, запакувати, отримати етикетку доставки, відвантажити й повідомити клієнту, де його посилка. Саме цю невидиму покупцю частину ми й наводили до ладу.
Про проєкт
Технічне завдання - це забезпечити продаж через не-шаблонний інтерфейс інтернет-магазину, на якому Ви можете обирати модель, марку та інші характеристики свого авто, після чого для Вас будуть підібрані відповідні килимки, кліпси та додаткові аксесуари.
Не виходячи за межі публічно відомих даних і NDA щодо устрою цього бізнесу, можна сказати наступне:
Програмне забезпечення компанії взаємодіє з багатьма сервісами - фулфілмент сервіс WAPI, поштова розсилка від Майкрософт, база моделей машин, реєстр штрих-кодів, окрема CRM система та деякі інші сервіси.
Проблеми та рішення
Ми прийшли не на порожнє місце, а в живу систему, яка вже продавала й виробляла. Це завжди складніше, ніж почати з нуля: зупиняти завод заради гарної архітектури ніхто не буде. Ось із чим ми зіткнулися.
- Архітектура. Система росла шарами, у міру того як з'являлися нові магазини, сервіси та завдання. Зв'язки між частинами були неочевидні, і правка в одному місці несподівано відгукувалася в іншому.
- Відсутність документації. Як влаштовані замовлення, статуси та інтеграції, знали окремі люди, а не документи. Будь-який новий розробник починав з археології.
- Легасі. Частину коду писали давно й поспіхом. Працює, але чіпати страшно, а чіпати доводиться.
- Багато тестування. Кожна зміна стосується живих замовлень і грошей. Перевіряти доводилося багато й вручну, а це повільно й дорого.
- Складні алгоритми. Підбір килимка під марку, модель, покоління, кузов і коробку передач, комплекти, кольори та фактури. Комбінацій дуже багато, і помилка тут означає виріб, який не підійде до машини.
- Складні інтеграції. Магазин, фулфілмент WAPI, поштові розсилки, база моделей машин, реєстр штрих-кодів, окрема CRM. У кожного сервісу свої правила, свої збої і свій темп.
- Асинхронні паралельні процеси. Замовлення надходять одночасно, статуси змінюють виробництво й доставка, і все це має сходитися в одну картину без гонок і дублів.
- Відкладені завдання. Багато що має статися не зараз, а пізніше: лист клієнту, оновлення статусу, повторний запит до зовнішнього сервісу. Якщо таке завдання тихо губиться, клієнт дізнається про це раніше за компанію.
Рішення
Почали з діагностики, а не з переписування. Спочатку зрозуміти, що є, потім вирішити, що змінювати, і лише потім змінювати.
- Аудит підсистем і ядра. Розібрали код, деплой і базу даних і зафіксували стан системи в окремому документі.
- Моніторинг процесів. Зробили так, щоб зависле замовлення чи інтеграція, що впала, були видні одразу, а не за скаргою клієнта.
- Рефакторинг. Не «все переписати», а мінімально необхідні перетворення, які наближають систему до стандартів і не зупиняють продажі.
- Автоматизація розгортання. Викладка нової версії перестала бути ручним ритуалом із завмиранням серця.
- Автоматизація доставки. Підібрали архітектурні рішення для безперервної інтеграції: зміни йдуть до користувачів короткими ітераціями.
- Автоматизація тестування. Повторювані перевірки забрали в людей і віддали тестам.
- Проєктування архітектури. Намалювали схеми «до», «після» і «перехід», щоб уся команда, включно з партнерами, бачила, куди і яким шляхом рухається система.
- Закриття вразливостей. Знайшли й закрили слабкі місця, які спливли на аудиті.
- Розробка модуля доставки. Зв'язали замовлення з фулфілментом WAPI: етикетки доставки, відвантаження, статуси посилки.
- Розробка модуля пакування. Пакування стало окремим кроком процесу зі своїм статусом, а не «десь між виробництвом і відправкою».
- Розробка модуля експорту та фін-звітів. Дані про замовлення вивантажуються для обліку й фінансової звітності без ручного зведення таблиць.
- Паралелізація. Важкі операції рознесли по паралельних процесах, щоб зростання замовлень не перетворювалося на чергу.
Результати
- Усунення втрати клієнтів. Збої, через які замовлення застрягали між магазином, виробництвом і доставкою, перестали тихо з'їдати клієнтів.
- Покращення продуктивності. Система швидше обробляє замовлення і не захлинається під навантаженням.
- Підвищення читабельності. Код став зрозумілішим, нові люди входять у проєкт швидше.
- Підвищення тестопридатності. Зміни можна перевірити до того, як вони зустрінуться з живими замовленнями.
- Покриття документацією. Знання про систему живуть у документах і схемах, а не лише в головах.
Про команду
У рамках роботи над проєктом ми зібрали робочу групу із системним архітектором, бізнес-аналітиком і трьома програмістами. Паралельно з нами на проєкті працювали наші партнери - британська компанія Wodo Ecom LLP (Лондон), їхній проєктний менеджер і спеціаліст з електронної комерції. Ми активно взаємодіяли з кількома представниками компанії та гнучко приймали, аналізували й впроваджували нові вимоги. Для якісної роботи над проєктом були організовані спеціальні зустрічі для проєктування та консолідації необхідних технічних процесів, робота була вибудувана в трекері, завдання декомпозувалися та деталізувалися в процесі, оскільки для цього проєкту не було можливості написати й затвердити повне технічне завдання через часті зміни у вимогах, а також необхідність коротких ітерацій і конвеєра доставки версій.
Висновки
Компанії Ingello можна довірити великі та нешаблонні проєкти. Ми не є найбільшою IT компанією на ринку, але в нас дуже глибокий підхід до розробки, наш досвід дає якісне розуміння клієнтів, їхніх компаній і внутрішніх процесів. Звертайтеся до нас із проєктами будь-якої складності.
Екрани та схеми
Спершу те, що бачить покупець. Картка товару працює як конструктор: фактура, колір килимка й окантовки, конфігурація комплекту, а нижче послідовний вибір марки, моделі, покоління, кузова й коробки передач. Ціна перераховується за обраним комплектом.
Обрали жовту окантовку й повний комплект, ціна змінилася.
Коли машину обрано, магазин показує орієнтовну дорогу замовлення: оформлено, у виробництві, відправлено, доставлено. Обіцянка покупцю, за якою стоїть уся внутрішня система.
У кошик замовлення потрапляє з усіма параметрами: фактура, кольори, модель автомобіля. Саме ці дані потім ідуть у виробництво.
Далі внутрішня кухня. Тека проєкту: аудит системи, документація, мінімально необхідні перетворення, підбір рішень для безперервної інтеграції, схеми «до, після, перехід», чорнова схема функціональності, схема листів клієнту з адмінки.
Схема процесу замовлення з фулфілментом WAPI: від замовлення в Shopify через перевірки, виробництво й етикетку доставки до відправлення та сповіщення клієнта.
Схема за ролями: що робить адміністратор, а що система, після того як замовлення з магазину підтверджено. Деталі розмито: це внутрішня кухня клієнта під NDA.
І документація, якої раніше не було. Зміст теж приховано за NDA, але сам факт її появи, мабуть, головний результат для будь-кого, хто розвиватиме систему далі.
Технології
Вітрина працює на Shopify, облікова частина написана на Laravel (PHP). Довкола інтеграції: фулфілмент WAPI, поштові розсилки Microsoft, база моделей автомобілів, реєстр штрих-кодів, окрема CRM. Плюс безперервна інтеграція, автоматичне розгортання й тести, які ми вибудували під час проєкту.
Де подивитися
Магазин працює, і пройти шлях покупця від вибору машини до кошика можна самому на сайті primeeva.com. Адміністративна частина й документація закриті: це внутрішні системи клієнта під NDA.
Схоже рішення: Автобусний букінг: система для перевізника від сайту до панелі власника.
