Custom Software · Поглиблено
Власна розробка чи платформа: сітка рішень build-vs-buy
Коли розробляти ПЗ на замовлення, а коли купувати платформу: сітка рішень на основі відповідності процесу, сукупної вартості володіння, lock-in, володіння даними та time-to-value.
АРХІТЕКТУРА · BUILD-VS-BUY
Вхід · Можливості, які треба увімкнути
Вихід · Будувати / Купити / Скомпонувати
Ядро vs комодіті (мапа цінності)
Розкладає систему на її спроможності й розміщує кожну на осі core/commodity: відділяє те, що вирізняє вас на ринку — і заслуговує на власний код, — від того, що стало commodity і просто купується у найдешевшого постачальника.
Відповідність процесу
Вимірює, наскільки пропрієтарний ваш потік: типовий процес з усталеними галузевими стандартами штовхає до платформи, а потік, що є частиною вашої переваги, штовхає до розробки на замовлення, бо тут обхідні рішення, нав’язані платформою, коштують дорожче за код на замовлення.
TCO на 5 років
Рахує вартість на п’ять років, включно із супроводом, інтеграцією та навчанням — не лише ліцензію чи початковий кошторис, — бо більша частина вартості ПЗ приходить після запуску, і саме це перевертає вердикт.
Lock-in і права виходу
Зважує вартість виходу до того, як увійти: контракти, переносність даних і жорстко вшиті інтеграції вирішують, чи матимете ви переговорну силу під час продовження, чи лишитеся без неї, перед постачальником, який це знає.
Власність на дані
Перевіряє, що дані, які вас вирізняють, лишаються вашими, експортовними у відкриті стандарти й незалежними від постачальника: один-єдиний неекспортовний елемент може перевернути рішення, бо актив, перетворений на заручника, важить більше за будь-яку економію на прайс-листі.
Час до цінності
Урівноважує терміновість цінності та довговічність переваги: перевірене, вже доступне рішення приводить вас у рух зараз, а структурний диференціатор виправдовує довше, витримане впровадження.
Ознаки того, що лінію build-vs-buy проведено не там
Питання ніколи не звучить «власна розробка чи платформа». Воно звучить так: яка спроможність заслуговує на власний код, а яка — commodity, яку купують. Ці симптоми означають, що лінію проведено не в тому місці.
- Ви кастомізуєте стандартну платформу доти, доки вона не перестає бути схожою на себе: кожен реліз постачальника ламає вашу конфігурацію, а «коробкове рішення» перетворилося на постійний проєкт розробки.
- Ви побудували commodity з нуля — автентифікацію, платежі, сповіщення — витративши інженерні потужності на задачі, які ринок уже розв’язав, замість вашої конкурентної переваги.
- Дані, що вас вирізняють, живуть усередині постачальника у пропрієтарному форматі без експорту у відкриті стандарти: це вже не актив, це заручник.
- Ніхто так і не порахував цифру на п’ять років : рішення ухвалили на основі ціни ліцензії чи кошторису розробки, проігнорувавши супровід, інтеграцію та навчання, які домінують у життєвому циклі.
- Змінити постачальника немислимо : багаторічні контракти, непереносні дані та жорстко вшиті інтеграції підняли вартість виходу до рівня, який позбавляє вас будь-якої переговорної сили під час продовження.
Для технічних та операційних директорів і керівників операцій, яким треба вирішити, куди вкладати інженерні потужності, а де спертися на ринок, з критеріями, що витримають перевірку перед радою директорів.
Купуй commodity, будуй те, що тебе вирізняє
Найстійкіше операційне правило не фінансове, а стратегічне: розмістити кожну спроможність на карті цінності й вирішувати за її положенням, а не за вподобаннями того, хто пише код. Дисципліна, формалізована у Wardley Mapping.
Core проти commodity, а не особистий смак
Спроможність, яка вирізняє вас на ринку та швидко розвивається, заслуговує на власний код. Спроможність, що стала commodity — однакова у вас і у конкурентів, — це центр витрат: її купують у найдешевшого постачальника й рухаються далі. Будувати commodity — означає палити інженерні потужності на вже розв’язаній задачі.
Відповідність процесу — ось справжня межа
Якщо ваш потік типовий, а в галузі є усталені стандарти, платформа виграє за швидкістю. Якщо потік пропрієтарний і частина вашої переваги, платформа нав’язує обхідні рішення, які в сумі коштують дорожче за код на замовлення. Платформа підганяє вас під свою модель; розробка на замовлення підганяє ПЗ під вашу.
Налаштування не безкоштовне
Між «купити» і «побудувати» є третій шлях — налаштувати та інтегрувати — але він не нейтральний. Вписати складну платформу в конкретний потік, з міграцією даних і навчанням, несе реальну вартість ще до першої транзакції. Пастка — надмірна кастомізація: почніть із рекомендованої конфігурації та ітеруйте за даними використання, не переписуйте все першого дня.
Compose: найкраще з обох, з дисципліною
Зрілий підхід гібридний: ринкові спроможності для стандартних функцій, з’єднані через документовані API, а внутрішні інженерні потужності зосереджені на тому, що вас по-справжньому вирізняє. Це логіка composable (мікросервіси, API-first, cloud-native, headless): замінні компоненти, що змінюються, не обвалюючи все, що з ними пов’язане.
Рішення має бути структурним, а не емоційним
Картування спроможностей робить вибір читабельним: видно, де кожен компонент перебуває на осі «генезис — commodity», від чого він залежить і куди штовхає еволюція. Лінія build-vs-buy перестає бути вподобанням відділу й стає захищуваним архітектурним рішенням.
Як ми проводимо лінію, спроможність за спроможністю
Ми не вирішуємо «власна розробка чи платформа» для всієї системи. Ми розкладаємо систему на спроможності й проводимо кожну через одні й ті самі ворота. Результат — карта, а не думка.
Розкладаємо систему на її спроможності й розміщуємо кожну на осі core/commodity: що вас вирізняє, що стало стандартом. Це відділяє те, що варте власного коду, від того, що ви просто купуєте.
Для кожної спроможності перевіряємо, наскільки пропрієтарний ваш потік. 60–70% стандарту з керованими винятками: налаштовувати. Потік, що є частиною переваги: будувати. Типовий потік: купувати.
Рахуємо вартість на п’ять років, включно із супроводом, інтеграцією та навчанням — не лише ліцензію чи початковий кошторис. Паралельно вимірюємо вартість виходу: переносність даних, права експорту, залежність від інтеграцій.
Кожна спроможність отримує вердикт — build, buy чи compose — і своє місце в архітектурі. Commodity йдуть за документовані API; диференціатор стає власним кодом, із даними під вашим контролем.
Від карти спроможностей до захищуваної сітки рішень за тижні, а не за квартал досліджень.
Build, Buy чи Compose: ворота рішення
Кожна спроможність проходить через п’ять важелів. Це не сума балів: один важіль може перевернути рішення (пропрієтарні, неекспортовні дані важать більше за будь-яку економію на прайс-листі).
| Важіль рішення | Штовхає до BUY / платформа | Штовхає до BUILD / на замовлення |
|---|---|---|
| Положення на карті | Спроможність commodity, ідентична конкурентам | Спроможність core, що вас вирізняє та швидко розвивається |
| Відповідність процесу | Типовий потік, усталені галузеві стандарти | Пропрієтарний потік; платформа нав’язує дорогі обхідні рішення |
| TCO на 5 років | Супровід і ризик несе постачальник | Обсяг і термін використання амортизують вартість розробки |
| Lock-in і вихід | Експорт у відкриті стандарти, вихід заради зручності, інтеграції через API | Критичні дані мають лишатися власними, незалежними від постачальника |
| Time-to-value | Цінність потрібна зараз; перевірене рішення вже доступне | Перевага виправдовує довше, витримане впровадження |
Чотири активи, які сітка тримає в безпеці
Грамотне рішення build-vs-buy оптимізує не лише вартість. Воно захищає те, що, втративши одного разу, вже не викупиш.
Володіння даними
Дані, що вас вирізняють, лишаються вашими — експортовними у стандартних форматах і незалежними від постачальника. Не заручник у пропрієтарному силосі, а торгований актив, що дає вам силу під час продовження.
Грамотно витрачені інженерні потужності
Кожна година розробки йде на вашу конкурентну перевагу, а не на commodity, яку ринок уже розв’язав. Своє там, де це важливо, ринок там, де не важливо.
Права виходу
Переносність даних, документовані інтеграції через API та відсутність пропрієтарної обв’язки тримають вартість переходу низькою. Можливість піти — це те, що утримує вас на чесних умовах.
Архітектура composable
Замінні спроможності, з’єднані через API: один компонент змінюється, не обвалюючи решту. Система лишається живою в часі, а не монолітом, який треба переробляти.
Будуй те, що тебе вирізняє, купуй те, що в тебе спільне з конкурентами.
Питання, які нам ставлять перед рішенням
Розробка на замовлення завжди дорожча за платформу?
Не на життєвому циклі. Більша частина вартості ПЗ приходить після запуску — супровід, інтеграція, навчання. На commodity платформа виграє, бо перекладає цю вартість на постачальника. На спроможності core з великим обсягом і довгим терміном використання розробка на замовлення амортизується, а ціна платформи з часом зростає. Відповідь — у TCO на п’ять років, а не в ціні входу.
Чи можу я купити зараз і побудувати пізніше?
Так, і часто це правильний хід — за умови, що ви не потрапите в пастку. Купити, щоб швидко стартувати, має сенс, якщо дані лишаються експортовними у відкриті стандарти, а інтеграції йдуть через документовані API. Якщо постачальник тримає ваші дані у пропрієтарному форматі, «пізніше» перетворюється на дорогу міграцію, яку ви ніколи не зробите. Переносність узгоджують під час підписання, а не під час розлучення.
Як уникнути побудови того, що ринок робить краще?
Картуючи кожну спроможність до написання коду. Якщо функція стала стандартом — однаковою у вас і у конкурентів, — її побудова це спалені інженерні потужності. Власний код відведено під те, що вас вирізняє та розвивається; усе інше купується або збирається через API. Ця дисципліна відділяє інвестицію від витрати.
Кейси
Від проблеми до результату — анонімно.
Викривлена платформа
Проблема Ритейлер кастомізував стандартну e-commerce-платформу доти, доки вона не перестала бути схожою на себе: кожен реліз постачальника ламав конфігурацію, а «коробкове рішення» перетворилося на постійний проєкт розробки, причому рушій ціноутворення — їхній справжній диференціатор — був затиснутий в обмеженнях, яких вони не контролювали.
Метод Ми картували спроможності на осі core/commodity: каталог, оформлення замовлення та платежі лишено на платформі як commodity за документованими API; рушій ціноутворення та промоакцій, частину конкурентної переваги, виокремлено у власний сервіс, підключений за принципом composable.
Результат Релізи постачальника перестали ламати систему, інженерні потужності повернулися до ціноутворення замість обхідних рішень, а логіка, що їх вирізняє, стала їхнім власним кодом — замінним без обвалу решти.
Дані в заручниках
Проблема Компанія фінансових послуг тримала клієнтські дані, що її вирізняли, всередині постачальника, у пропрієтарному форматі без експорту у відкриті стандарти: змінити було немислимо, і під час продовження вся переговорна сила була в постачальника, бо вихід був фактично закритий.
Метод Ми застосували ворота lock-in і володіння даними: переузгодили права експорту у стандартні формати під час розірвання контракту, перенесли критичні інтеграції на документовані API і повернули диференціювальні дані під внутрішній контроль, лишивши функції commodity там, де вони були.
Результат Вартість виходу впала до рівня, що відновив переговорну силу під час продовження, дані знову стали торгованим активом замість заручника, а можливість піти — це те, що утримало їх на чесних умовах.
Commodity, побудована з нуля
Проблема Логістичний оператор побудував з нуля спроможності, що вже стали commodity — автентифікацію, сповіщення, керування користувачами — палячи інженерні потужності на задачах, які ринок уже розв’язав, тоді як планування маршрутів, їхня справжня перевага, лишалося недоінвестованим.
Метод Ми провели кожну спроможність через карту цінності та TCO на п’ять років: вивели з експлуатації розробку на замовлення для commodity на користь ринкових сервісів за API і зосередили розробників на оптимізації маршрутів, де обсяг і термін використання амортизують код на замовлення.
Результат Кожна година розробки повернулася до диференціатора, супровід commodity перейшов до постачальників, а архітектура стала composable — замінні компоненти, що змінюються без переробки всього блоку.
Заглибитися ще