Чему построение систем учит о их покупке

Почему техническая архитектура важна в 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 должен изучать глубину реализации, не просто наличие ИИ. Вопрос не в том, использует ли компания ИИ, почти любой современный цифровой бизнес ответит да. Более полезный вопрос, где реально живёт дифференциация компании, и что выживет, если сменится ИИ-провайдер.

ЗАВИСИМОСТЬ ОТ ОСНОВАТЕЛЯ

Зависимость от основателя тоже технический риск

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

Это обычно называют зависимостью от основателя или риском ключевого человека. Но базовая проблема шире: знание, что не стало организационной способностью.

Исходный код может перейти. Учётные данные сервера могут перейти. Контракты могут перейти. Знание может не перейти.

Компания может иметь сотни страниц документации и всё равно иметь значительную зависимость от ключевого человека. Документация фиксирует то, что кто-то решил задокументировать. Она не обязательно фиксирует исключения, исторические решения, незадокументированные зависимости, специфичное для клиента поведение, операционное суждение, институциональное знание, отношения. Так что вопрос не должен быть просто задокументирована ли система. Лучший вопрос, смогла бы другая компетентная команда эксплуатировать, поддерживать, и развивать эту систему без людей, что изначально её построили. Это значительно более осмысленный тест передаваемости, а передаваемость один из центральных вопросов в приобретении.

СЛОЖНОСТЬ ПРОТИВ РИСК

Техническая сложность, это не то же самое, что технический риск

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

Так что технический due diligence не должен просто спрашивать, насколько сложна эта система. Он должен спрашивать, насколько сложно было бы покупателю эксплуатировать, заменить, или изменить её.

Практическая модель технического риска

Зависимость × Заменимость × Влияние на бизнес

Технический риск растёт, когда зависимость высока, замена сложна, и влияние на бизнес значительно.

Это более полезная призма, чем подсчёт технологий, репозиториев, интеграций, или строк кода.

ЧТО ПЕРЕСТРОИТЬ

Что покупателю пришлось бы перестроить?

Именно здесь архитектура встречается с логикой сделки. Покупатель может реально платить не за софт. Он может платить, чтобы избежать перестройки возможности. Представь возможность, что новой команде понадобился бы год или больше, чтобы воспроизвести. Ценность не обязательно в самом исходном коде. Она может быть в комбинации софта, интеграций, структур данных, воркфлоу, инфраструктуры, специализированного знания, внутренних инструментов, миграции клиентов, операционных процессов.

Это уравнение строить-против-покупать с другой стороны сделки. Архитектурный вопрос, стоит ли строить эту возможность или купить её. Вопрос 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 быть полезен до приобретения?

Да. Те же вопросы полезны задолго до сделки: чем бизнес владеет, что арендует, где живёт знание, что может сломаться, и что пришлось бы перестроить, если бы критическая зависимость исчезла.