Чого побудова систем навчає про їх купівлю

Чому технічна архітектура важлива в M&A і технічному due diligence, і чого покупці можуть навчитись у людей, що реально будують системи, які купують.

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

І вона може назвати все це активами.

Покупцю доводиться поставити інше питання: що конкретно ми купуємо?

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

Словник змінюється, коли розмова переходить від архітектури до M&A. Діагностична дисципліна ні.

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

ПОКУПЕЦЬ БАЧИТЬ БУДІВНИЧИЙ ЗНАЄ

Що покупець бачить там, де будівничий вже навчився

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

Саме тому технічна архітектура може бути важлива в M&A, навіть коли сама угода не в першу чергу про технологію. Питання не в тому, чи використовує компанія сучасний софт, а в тому, скільки з її реальної можливості компанія реально контролює.

ЧОМУ ВАЖЛИВО

Чому технічна архітектура важлива в due diligence при M&A

Фінансовий due diligence і юридичний due diligence відповідають на найважливіші питання. Виручка. Контракти. Маржа. Зобов'язання. Володіння. Передача інтелектуальної власності. Корпоративна структура. Ці дисципліни спроєктовані перевіряти саме це.

Технічний due diligence відповідає на іншу категорію питань. Чи технологія реально проприєтарна? Чи «кастомна платформа» реально кастомна? Які системи критичні для операцій? Які вендори можуть суттєво вплинути на бізнес? Де живуть дані компанії? Що станеться, якщо ключовий провайдер змінить ціни чи умови? Чи може система працювати без людей, що спочатку її побудували? Скільки коштувало б замінити критичні компоненти?

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

ЧИМ ВОЛОДІЄ КОМПАНІЯ

Чим компанія реально володіє?

Технологічний стек каже, що система використовує. Він не обов'язково каже, чим володіє бізнес.

Розглянь компанію, що описує свою клієнтську платформу як проприєтарну. Очевидні питання технічні: це Laravel, React, AWS, PostgreSQL, щось інше? Ці деталі важливі, але це не перше питання. Перше питання, яку бізнес-можливість реально дає ця система. Далі, яка частина цієї можливості проприєтарна, які частини commodity-інфраструктура, які залежності можна замінити без суттєвої зміни бізнесу, і які залежності створили б значний операційний ризик, якби зникли.

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

ПОБУДОВАНО ПРОТИ ОРЕНДОВАНО

Побудовано проти орендовано: знайти реальний проприєтарний шар

Кожна серйозна архітектура містить те, чим володіють, і те, що орендують.

Чим бізнеси реально володіють проти орендують

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

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

АКТИВ ЗНАНЬ

Коли цифрове знання стає активом, а коли ні

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

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

Бізнес накопичив інформацію швидше, ніж побудував систему, здатну її представити.

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

Актив і система, що робить актив корисним, це дві різні речі.

ШІ ФУНКЦІЯ ПРОТИ МОЖЛИВІСТЬ

ШІ-функція, це не те саме, що ШІ-можливість

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

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

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

ЗАЛЕЖНІСТЬ ВІД ЗАСНОВНИКА

Залежність від засновника теж технічний ризик

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

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

Вихідний код може перейти. Облікові дані сервера можуть перейти. Контракти можуть перейти. Знання може не перейти.

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

СКЛАДНІСТЬ ПРОТИ РИЗИК

Технічна складність, це не те саме, що технічний ризик

Складність видима. Залежність ні. Складна архітектура може бути модульною, задокументованою, відстежуваною, замінюваною, зрозумілою кільком людям. Проста архітектура може залежати від одного вендора, залежати від одного співробітника, бути неможливою замінити швидко, повною незадокументованих винятків.

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

Практична модель технічного ризику

Залежність × Замінюваність × Вплив на бізнес

Технічний ризик зростає, коли залежність висока, заміна складна, і вплив на бізнес значний.

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

ЩО ПЕРЕБУДУВАТИ

Що покупцю довелось би перебудувати?

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

Це рівняння будувати-проти-купувати з іншого боку угоди. Архітектурне питання, чи варто будувати цю можливість чи купити її. Питання M&A, що довелось би побудувати, якби ми не купили цю компанію. Це фундаментально пов'язані питання.

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

ЩО ВИВЧАЄ ДІЛІДЖЕНС

Що реально вивчає технічний due diligence

Огляд коду питає, чи здоровий софт. Технічний due diligence питає, що технологія реально означає для бізнесу. Це означає вивчення щонайменше кількох шарів.

Це не замінює фінансовий чи юридичний due diligence. Це заповнює інший шар картини.

ІНШИЙ ПОГЛЯД НА ДАТА-РУМ

Інший спосіб дивитись на дата-рум

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

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

Саме тут технічна діагностика стає більшою, ніж оглядом технології. Вона стає оглядом переданості.

СЛОВНИК ЗМІНЮЄТЬСЯ

Словник змінюється. Діагностична дисципліна ні

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

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

Ми не починали писати про due diligence, а потім шукати докази. У нас спочатку були докази, роки доказів, і врешті ми помітили, доказом чого вони були.

Словник змінюється. Контекст змінюється. Угода змінюється. Діагностична дисципліна ні.

Чому технічна архітектура важлива в M&A due diligence?

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

Технічний due diligence, це те саме, що аудит коду?

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

Чи означає використання SaaS, що в компанії немає проприєтарної технології?

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

Що покупцю варто спитати про продукт з ШІ?

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

Чому залежність від засновника важлива технічно?

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

Чи може технічний due diligence бути корисним до придбання?

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