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

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

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

Тут немає однієї правильної відповіді — є одне правильне правило: залишки веде рівно одна система, а решта їх отримують. У частини компаній це буде Base, в інших — ERP або WMS, а при простій одноканальній моделі — сам Shopify. Ключове — щоб напрямок оновлення був одностороннім і чітко визначеним. Двостороння синхронізація залишків без чіткого правила — найчастіша причина розбіжностей.

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

Частину з них зазвичай так — найчастіше застосунки для відправок, етикеток, виставлення рахунків або простих автоматизацій. Це не автоматично, і варто перевірити це свідомо, бо дублювання функцій між Base і застосунками Shopify призводить до конфліктів: два інструменти змінюють той самий статус або генерують той самий документ. Інвентаризація застосунків — один з елементів аудиту.

Починаємо з розуміння фактичного стану, а не з перебудови. Старіші конфігурації зазвичай містять автоматизації, додані етапами, первісне обґрунтування яких уже ніхто не пам'ятає. Спершу картуємо реальний потік даних, потім відокремлюємо те, що працює правильно, від того, що створює ризик, і лише тоді пропонуємо зміни — зазвичай етапами, починаючи з quick wins, які не вимагають зачіпати архітектуру.

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

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

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

Base дозволяє зібрати обслуговування перевізників (Нова Пошта, міжнародні кур'єри) в одному місці: правила вибору перевізника, генерація етикеток, оформлення відправлень і передача номерів у системи продажу та клієнту. Цінність з'являється насамперед при більшому обсязі й кількох перевізниках. Варто спроєктувати це разом зі складським процесом — особливо логіку багатопакування й розділених замовлень, яку типова конфігурація зазвичай не обробляє добре.

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

Аудит проводимо наживо на ваших акаунтах Shopify і Base, тож потрібен доступ із правами переглядати конфігурацію, замовлення й автоматизації — без потреби вносити зміни. Корисним є також контакт з людиною, яка знає операційні й складські процеси. Ви зберігаєте контроль над акаунтами й даними; доступи можна відкликати в будь-який момент. Час підготовки звіту визначаємо при замовленні аудиту, залежно від складності конфігурації.

Скажемо це прямо й вкажемо іншу архітектуру. Іноді правильною відповіддю є впорядкування самого Shopify й заміна кількох застосунків, іноді — сильніша опора процесів на ERP чи WMS, а іноді — зміна порядку дій: наприклад, спершу порядок у товарних даних, а вже потім новий операційний рівень. Звіт з аудиту має цінність незалежно від того, чи його висновком є впровадження Base.