Софт має підходити бізнесу

Чому цифрова трансформація починається з бізнес-архітектури, не з вибору платформи.

Більшість цифрових проєктів починаються не з того питання.

Яку платформу використати? Shopify чи Adobe Commerce? Salesforce чи іншу CRM? SaaS чи кастом? Headless чи моноліт? Будувати чи купувати?

Це легітимні питання. Просто не перші.

Перше питання складніше: що цьому бізнесу реально потрібно, щоб його цифрові системи розуміли?

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

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

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

САЙТ НЕ БІЗНЕС

Сайт, це не бізнес

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

B2C-клієнт може пройти шлях: товар → кошик → чекаут → оплата → доставка. B2B-клієнт може пройти шлях: акаунт → погоджені умови → каталог → котирування → схвалення → замовлення → виконання → рахунок. Дилер може піти зовсім іншим шляхом. Сайт лише те місце, де частина цих шляхів стає видимою.

На певному масштабі e-commerce стає інтерфейсом в операційну систему компанії, точно той зсув, розібраний ширше у цифровій архітектурі, і щойно це відбувається, реальні архітектурні питання більше не візуальні. Вони стають питаннями володіння. Де живе правда про товар. Хто володіє записом клієнта. Яка система володіє ціною. Де інвентар стає авторитетним джерелом. Хто володіє замовленням. Що належить сайту. Що належить ERP. Що належить CRM. Що має лишитись товарною послугою. І яка частина системи достатньо важлива, щоб бізнес володів нею постійно.

Саме це останнє питання більшість розмов про платформи ніколи не досягають.

CRM ПАСТКА SHTAYER

CRM-пастка, на практиці: як SHTAYER переріс свій софт

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

Один з наших давніх проєктів, SHTAYER, чия власна історія бренду розказана у побудові бренду для нового покоління, розпочався у 2019 році з відносно простої цифрової вимоги: e-commerce магазин і невелика лендинг-присутність для B2B клієнтів. Безпосередньою бізнес-проблемою були продажі. Компанії потрібно було побудувати відділ продажів, організувати взаємодію з клієнтами, і створити більш структурований комерційний процес. Логічною відповіддю була CRM. На тій стадії це була правильна відповідь.

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

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

Кожен успішно вирішений шар може оголити наступну відсутню систему.

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

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

Вимога змінилась з кращої CRM на кращу модель бізнесу, точно те розрізнення, розібране ширше у кастомній CRM проти ERP, і більш практично у яка CRM підходить твоєму бізнесу. CRM спроєктована керувати відносинами з клієнтами. Вона автоматично не спроєктована розуміти, як конкретна компанія закуповує матеріали, керує товарами, координує виробництво, обробляє замовлення по ринках, чи повʼязує комерційну активність з операційною реальністю. У певний момент бізнесу потрібно більше, ніж система продажів. Йому потрібна система, що розуміє, як працює сам бізнес, і навіть назвати це ERP неповно, бо відповіддю ніколи не було просто додати ERP до наявного стеку. Бізнес вже переріс архітектуру, з якою починав, тож сама цифрова платформа мала еволюціонувати.

Те, що почалось як e-commerce з невеликою B2B-присутністю, стало повноцінним цифровим комерційним і операційним середовищем: повноцінний B2B-сайт, суттєва B2C e-commerce платформа, шар застосунку на Laravel, кастомна ERP, і адміністративне середовище, повʼязане з усією системою. ERP не обирали ізольовано і не нав'язували бізнесу. Її проєктували навколо вимог, що бізнес виявив за роки реальної роботи: звʼязки між матеріалами і товарами, постачальниками і замовленнями, виробництвом і виконанням, різними ринками і країнами, відносинами з клієнтами, комерційними процесами, і фінансовими операціями.

Кастомна ERP не початок трансформації. Вона її наслідок.

Не було причини будувати проприєтарну ERP на початку. CRM була правильною відповіддю на проблему, що існувала тоді. Пізніше більш здатна CRM набула сенсу. Ще пізніше бізнесу знадобились можливості, що більше не вміщались природно всередину CRM. Архітектура змінилась, бо бізнес змінився, значно кориснішим способом думати про кастомний софт: будуй, коли бізнес став занадто специфічним, занадто взаємоповʼязаним, чи занадто стратегічно важливим, щоб бути правильно представленим типовим продуктом.

Клієнт розміщує замовлення. Товар має існувати. Матеріал має бути доступним. Постачальник має доставити. Операція має його обробити. Замовлення має просунутись. Фінансовий запис має існувати. І відносини з клієнтом мають лишитись незмінними. Софт успішний лише коли ці реальності можуть співіснувати всередині однієї узгодженої архітектури.

Як реально еволюціонувала архітектура SHTAYER

Бізнеси рідко перероcтають CRM, бо CRM замала. Вони переростають її, бо бізнес став більшим за проблему, для вирішення якої спочатку обрали CRM.

SHTAYER показує, що відбувається, коли бізнес виявляє свою архітектуру через роки операційного зростання. Schoeffel представив протилежний виклик: що відбувається, коли у бізнесу є можливість спроєктувати цю архітектуру навмисно, до того як побудовано наступне покоління бізнесу.

Два шляхи до однієї архітектури

ЯКА CRM ЗАМАЛА

Питання «Яка CRM» може вже бути замалим

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

Аналіз виявив окремі вимоги для закупівель і партій перлин, стоку і замовлень, виробництва, атрибутів товару, медіа і документів, відносин з клієнтами, clienteling, ціноутворення по ринках, і бухгалтерії. Коли ці вимоги класифікували за типом системи, лише один з семи блоків реально був CRM у вузькому сенсі. Решта належали ERP, OMS, PLM, PIM/DAM, бухгалтерії, чи специфічному для бізнесу шару clienteling.

Це повністю змінює розмову. Вендор софту може продати тобі CRM. Архітектурна вправа ставить інше питання: які системи мають існувати, де вони мають жити, і хто має володіти майстер-записом для кожного критичного обʼєкта?

Це питання бізнес-архітектури. І на нього потрібно відповісти до технологічного рішення.

БЕНЧМАРК ДО АРХІТЕКТУРИ

Ми бенчмаркували категорію до вибору архітектури

Для Schoeffel ми не хотіли формувати думку на основі жменьки знайомих конкурентів, точно та дисципліна, розібрана ширше у Product Discovery. Ми вивчили тридцять брендів в основній вибірці, три додаткові бренди для перевірки структури, і один додатковий референсний бренд. По основній вибірці вісімнадцять брендів вдалось привʼязати до конкретної архітектури, використовуючи технічні відбитки на кшталт структури URL, метаданих, шляхів CDN, платіжних методів, і форматів локалізації, поряд з прямим оглядом клієнтського шляху і зафіксованим рівнем впевненості для кожної знахідки.

Це дало значно кориснішу картину, ніж список технологічних логотипів. Серед архітектур, що вдалось ідентифікувати, були Salesforce Commerce Cloud, Adobe Commerce, Adobe Experience Manager, Shopify Plus, WooCommerce, Next.js з Contentful, і повністю проприєтарна платформа. Шістнадцять з вісімнадцяти ідентифікованих впроваджень використовували SaaS чи ліцензований PaaS, з невеликою кількістю брендів, що виділялись як приклади, де сам цифровий досвід став стратегічним активом.

Ця знахідка прибрала легкий аргумент. Ми не могли чесно сказати, що люксовим брендам потрібен кастомний софт, бо SaaS не може створити витончений досвід. Бенчмарк показав протилежне. Красиві цифрові досвіди можна побудувати на Salesforce, на Adobe, на Shopify. Сама платформа не диференціатор. Важливе питання в тому, що відбувається після першого запуску.

ДВАДЦЯТА ЗМІНА

Двадцята зміна важливіша за перший запуск

Новий сайт легко романтизувати. Все нове: візуальна система, сторінки товарів, навігація, технологія. Але реальний тест архітектури відбувається пізніше. Пʼятий ринок. Десята кампанія. Новий потік дилера. Нова родина товарів. Нова локалізація. Нова логіка ціноутворення. Новий конфігуратор. Новий клієнтський шлях. Інтеграція, що ніхто не передбачив трьома роками раніше. Саме там архітектура себе розкриває, точно те місце, розібране ширше у прихованій вартості вибору неправильної архітектури.

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

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

ВОЛОДІЙ АБО ОРЕНДУЙ

Володій тим, що відрізняє. Орендуй те, що комодитизоване

Це стало центральним архітектурним принципом. Не все має бути кастомним. Будувати все самому може бути настільки ж ірраціонально, як віддавати все на аутсорс у SaaS. Платежі, це commodity. Антифрод, це commodity. Розрахунок податків може бути commodity. Інфраструктура доставки може бути commodity. Саму інфраструктуру часто можна орендувати. Мало стратегічної переваги у перебудові того, що ринок вже добре вирішує.

Але те, що робить бізнес іншим, це інше питання. Для люксового перлинного дому це може включати модель товару, логіку перлинних родин, ціноутворення по ринках, те, як клієнт відкриває товар, колекційну логіку, clienteling, чи відносини між редакційним знанням і самим товаром, той самий багаторинковий рівень складності, розібраний у мультикраїновому e-commerce для великих каталогів, точно той тиск конкретної категорії, розібраний у чому люксовий e-commerce порушує всі правила conversion optimization. Це не взаємозамінні commodities.

Чотири підходи до одного архітектурного рішення

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

ВОЛОДІТИ СИСТЕМОЮ

Що реально означає володіти цифровою системою

Для Schoeffel запропоновану архітектуру навмисно розділили на шари. Доменне ядро, побудоване на Laravel, вибір, розібраний на власних умовах у Laravel проти Symfony, володіє атрибутами товару і перлин, родинами відбору, ціноутворенням по ринках, замовленнями, клієнтами, податковою логікою, і правилами «ціна за запитом». Вітрина на Next.js контролює клієнтський досвід, серверний рендеринг, модульний контент, наративну навігацію, і чекаут. Адміністративне середовище, побудоване на Vue через Inertia, тримає контент, дані товару, параметри відбору, і операції з замовленнями близько до ядра. Товарні послуги, платежі, PCI, податки, доставка, email, і інфраструктура, лишаються керованими сервісами, що можна замінити за потреби.

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

Технологічний стек, це список інструментів. Архітектура, це карта відповідальності і володіння.

МОДЕЛЬ ВИЗНАЧАЄ СИСТЕМУ

Бізнес-модель визначає систему

Розглянь два бізнеси. Обидва продають фізичні товари онлайн. Було б спокусливо дати їм одну архітектуру. Це було б помилкою. У одного можуть бути складні матеріали, закупівлі, виробництво, міжнародні постачальники, інвентар, і продажі і B2B, і B2C. У іншого може бути мережа дилерів, кілька люксових ринків, складні звʼязки товарних родин, різні воронки продажів, clienteling, і висококонтактні B2B і B2C взаємодії.

У обох є e-commerce. Обом може знадобитись CRM. Обом може знадобитись ERP. Але причина, чому їм потрібні ці системи, різна, і тому архітектура має бути різною.

У бенчмарку Schoeffel сайт картували проти восьми окремих областей: товар і каталог, замовлення і оплата, візити в бутик, clienteling, ціни і ринки, контент і кампанії, закупівлі і склад, бухгалтерія і звітність. Вправа не припускала, що все належить сайту. Закупівлі, склад, і бухгалтерію явно винесли у зовнішні системи. Ця межа, що належить цифровому продукту і що належить деінде, одне з найскладніших рішень в архітектурі, і одне з найзначущіших.

Це стає особливо важливим, коли компанія продає і B2B, і B2C. Споживачу може знадобитись гарний досвід відкриття товару, ясне ціноутворення, чекаут, оплата, виконання, і постпродажний сервіс. Бізнес-клієнту можуть знадобитись структури акаунтів, погоджені ціни, каталоги під конкретного клієнта, підтримка продажів, котирування, схвалення, замовлення на закупівлю, повторювані замовлення, рахунки, дилерська логіка, і відносини, що тривають роки, не хвилини. Це різні комерційні системи, не просто різні шаблони, розрізнення, розібране глибше з дизайнерського боку у Product Design проти UX/UI, і у коли e-commerce стає бізнес-системою. Спільна модель товару може мати сенс. Спільна модель інвентаря може мати сенс. Ідентичність клієнта може потребувати обʼєднання. Ціноутворення, чекаут, воркфлоу продажів, і дозволи можуть не потребувати.

ECOMMERCE ОПЕРАЦІЙНА СИСТЕМА

E-commerce стає частиною операційної системи

Є точка, в якій платформа e-commerce перестає бути каналом продажів і стає частиною операційної інфраструктури, точно те питання, розібране напряму у що відбувається з e-commerce, коли сайт перестає бути сайтом. У цій точці сторінка товару зʼєднана з інформацією про товар. Інформація про товар зʼєднана з інвентарем. Інвентар зʼєднаний з закупівлями. Закупівлі зʼєднані з постачальниками. Замовлення зʼєднані з виконанням. Клієнти зʼєднані з CRM. Фінансові події зʼєднані з бухгалтерією. Маркетингова активність зʼєднана з поведінкою клієнта. І сайт сидить на перетині всього цього.

Чим більш взаємоповʼязаний бізнес, тим менше сенсу в оцінці платформи e-commerce ізольовано.

ЕКОНОМІКА СОФТУ

Економіка софту змінюється з ростом бізнесу

Вартість платформи, це не лише вартість ліцензії. Є впровадження, інтеграції, застосунки, залежність від агенції, підтримка, міграція, трансформації даних, і вартість кожної незвичайної вимоги, що зʼявиться пізніше.

У бенчмарку Schoeffel економіку платформи моделювали на пʼять років і три сценарії виручки, з важливим розрізненням: вартість платформи може бути привʼязана до виручки, поки проприєтарне ядро насамперед привʼязане до змін, що бізнес реально вирішує зробити, точно та залежність, що варто виявити до придбання, розібрана у як аудувати цифровий продукт перед купівлею. Глибша думка не в тому, що проприєтарні системи завжди дешевші. Це не так. Думка в тому, що економіка має різну форму. Одна модель фактично каже, чим успішнішим ти стаєш, тим більше платформа бере участь в економіці цього успіху. Інша каже, ти платиш за здатність, коли змінюєш систему, не просто тому що бізнес виріс.

Яка модель має сенс, залежить від бізнесу. Але це має бути свідоме архітектурне рішення, не рішення за замовчуванням.

КАСТОМ НЕ АВТОМАТИЧНО КРАЩИЙ

Кастомна система не автоматично краща система

Це достатньо важливо, щоб сказати явно. Ми не вважаємо, що кастомний софт за своєю суттю переважає SaaS. Це лише замінило б одну догму іншою.

SaaS чудовий, коли бізнес-процес стандартизований, і вендор вирішує цей процес краще, ніж компанія могла б розумно вирішити його сама. Кастомний софт стає цікавим, коли бізнес містить можливості, що занадто специфічні, занадто взаємоповʼязані, чи занадто стратегічно важливі, щоб віддавати на аутсорс типовому продукту. Гібридна система часто навіть краща: використовуй SaaS там, де ринок вже дає сильне commodity-рішення, володій шарами, де бізнес інший, і зʼєднуй їх навмисно.

Архітектура має слідувати за економікою і операційною моделлю. Ніколи за ідеологією.

БРЕНДИ ПОГАНО ПОЯСНЮЮТЬ

Більшість брендів погано пояснюють себе

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

Це важливо зараз, бо пошук змінюється. Асистент, що відповідає «що таке перлина Акойя», не потребує ще однієї люксової домашньої сторінки. Йому потрібне авторитетне пояснення. Питання про бренд потребує джерела, що реально пояснює бренд. Питання про походження потребує атрибутованих фактів. Питання про конкретний товар потребує структурованої інформації про товар.

Знімок нашого бенчмарку виявив, що для кількох реальних питань покупців про перли, пошукові і асистент-орієнтовані відповіді домінували інституції, гайди, рітейлери, форуми, і сторонні огляди. Самі перлинні доми часто були відсутні, чи зʼявлялись лише тому, що їх описало інше джерело. Це створює незвичайну можливість. Компанії не обовʼязково потрібно перевитратити конкурента зі столітньою історією, щоб стати авторитетним джерелом. Їй потрібно пояснити те, що вона знає, той самий розрив, розібраний з боку перекладу у багатомовному AEO.

ПЛАТФОРМА ІНША РОБОТА

У цифрової платформи тепер інша робота

Тут архітектура стає ще цікавішою. Платформа має не лише продавати. Вона має знати. Вона має зʼєднувати бренд, товар, атрибути, походження, автора, контент, ринок, і клієнта, і розкривати цю інформацію послідовно людям, пошуковим системам, і ШІ-системам. Це вимагає контролю над шаблонами, контролю над структурованими даними, контролю над локалізацією, узгодженого іменування сутностей, і даних контенту і товару, що діляться однією базовою моделлю.

В архітектурі Schoeffel SEO, AEO, GEO і E-E-A-T тому не маркетингові прикраси, додані після розробки. Структуровані дані, розмітка товару і організації, машинозчитувані відповіді, авторство, походження, локалізація і hreflang сидять всередині самої архітектури, той самий шаруватий підхід, що стоїть за SEO знаходить тебе, AEO рекомендує тебе, комерційна інфраструктура тебе купують.

У категорії вже є живий чат. Є WhatsApp. Є людські спеціалісти. Але це не те саме, що асистент, що розуміє реальний товар. Архітектура, розроблена для Schoeffel, ставиться до майбутнього асистента не як до віджета, приклеєного на сайт, а як до функції базової доменної моделі. Асистент має вміти читати атрибути товару, розуміти доступність, пояснювати логіку відбору, відповідати кількома мовами, знати, коли передати розмову людині, і відмовлятись вигадувати ціну чи доступність, коли базова система не містить цю інформацію, точно те розрізнення між реальною здатністю і поверхневим твердженням, розібране у проблемі AI Wrapper.

Чатбот може сидіти поверх сайту. Корисний бізнес-асистент має сидіти поверх бізнес-знання. І бізнес-знання має десь існувати першим.

ПЛАТФОРМА НЕ АКТИВ

Платформа, це не актив

SaaS-платформи неймовірно здатні, саме тому їх використовує так багато великих брендів: Salesforce Commerce Cloud, Adobe Commerce, Adobe Experience Manager, Shopify Plus всі можуть створити виняткові досвіди, наш бенчмарк це ясно продемонстрував. Тож питання не може бути просто, яка платформа найсильніша. Важливіше питання, які частини цифрового досвіду мають стати активом самого бізнесу.

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

ВПРОВАДЖЕННЯ НЕ АРХІТЕКТУРА

Впровадження, це не архітектура

Проєкт впровадження питає, як налаштувати цю платформу. Архітектура питає, що має існувати, чому це має існувати, де це має жити, і хто має цим володіти. Впровадження починається з софту. Архітектура починається з реальності. Впровадження питає, як зʼєднати системи. Архітектура вирішує, чи мають ці системи взагалі бути окремими. Впровадження оптимізує рішення. Архітектура визначає, що є рішенням.

Саме тому найважливіша робота над цифровим проєктом може відбуватись до того, як написано перший рядок продакшн-коду. Технологія не найскладніша частина, є чудові інструменти майже для всього. Складна частина, вирішити, що бізнес реально є: де закінчується один процес і починається інший, які дані авторитетні, який воркфлоу стратегічно важливий, які можливості взаємозамінні, які залежності небезпечні, які системи мають бути замінними, і які мають стати постійними активами. Що відбувається, коли компанія входить в іншу країну. Що відбувається, коли вона додає B2B. Що відбувається, коли зростає B2C. Що відбувається, коли змінюється воронка продажів. Що відбувається, коли каталог товарів ускладнюється. Що відбувається, коли компанії потрібна ще одна ERP. Що відбувається, коли ШІ стає частиною клієнтського шляху. На жодне з цих питань не відповідає вибір Shopify, Salesforce, Adobe, чи Laravel. На них відповідає розуміння бізнесу.

Найцінніший цифровий проєкт тому не редизайн сайту, не впровадження ERP, не міграція CRM, і навіть не перебудова e-commerce. Це проєктування цифрової моделі компанії, в якій у клієнтів є відносини, у товарів є структура, у цін є правила, у замовлень є життєві цикли, у матеріалів є походження, у ринків є логіка, у операцій є воркфлоу, у систем є відповідальність, і бізнес володіє шарами, що роблять його іншим. Іноді ця модель буде переважно SaaS. Іноді переважно кастом. Часто це буде гібрид. Важливо, чи слідує архітектура за бізнесом, не навпаки.

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

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

Спроєктуй бізнес цифрово спочатку. Потім обери технологію, що заслуговує його нести.

Принцип володіння архітектурою Peretz

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

Чому бізнесу не варто починати цифровий проєкт з вибору платформи?

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

Чи означає потреба в CRM автоматично, що бізнесу потрібно купити CRM-софт?

Не обовʼязково. «CRM», це часто перше імʼя, що бізнес дає проблемі, яку ще не повністю картував. Щойно залучені клієнти, товари, матеріали, постачальники, виробництво, і фінансові процеси, CRM може вирішувати лише одну частину більшої системи, що реально може потребувати ERP, PIM, OMS, кастомного софту, чи якогось поєднання, вирішеного тим, що реально вимагає кожна частина бізнесу.

Чи завжди кастомний софт кращий, ніж SaaS?

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

Що реально означає «володіти» цифровою системою на практиці?

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

Чому структурований, машинозчитуваний контент важливий для цифрової архітектури бізнесу?

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