Как видно из графиков, риски, связанные с титулом ПО, являются самыми распространенными (88% респондентов), а также самыми критичными (95% респондентов).

Это не значит, что кроме ПО в ИТ-проектах все остальное второстепенно. Но ПО (особенно в продуктовых бизнесах) является ценнобразующим активом номер один. Особенно, если у него уже есть рынок и сохраняется потенциал роста.

Даже в относительно небольших проектах (3-5 лет) проектах в рамках продукта могут существовать десятки крупных проприетарных компонентов (подсистем, модулей), особенно в тех, что имеют архитектуру супераппов. В том числе в прод-версии.

Что делать с проверкой такого продукта? Проверять все сплошняком по принципу «что дадут, то и проверим» — не эффективно. ПО тоже нужно проверять осознанно (простите 😃). Иначе может получиться ситуация, когда проверили то, что легко переписать / заменить, но оставили без внимания то, что было действительно важно.

Как понять, что в продукте важно / критично (это решают не юристы)?

Для этого можно использовать подход архитектурной декомпозиции продукта, что позволит сузить периметр проверки до наиболее значимых объектов и процессов.

Классифицировать ОИС в составе продукта по степени их существенности для бизнеса может техническая и операционная команда компании с учетом позиции приобретателя бизнеса, его планов по интеграции и стратегического развития продукта.
💠💠💠

При определения порога материальности соответствующих компонентов продукта, чаще всего учитывается комплекс критериев, в частности:

1️⃣Влияние на финансовый результат

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

2️⃣ Функциональность

Оценивается, какие компоненты IT-решения носят системообразующий характер и составляют его функциональное ядро, а какие представляют собой дополнительные опции, в том числе подключаемые бесплатно.

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

3️⃣ Безопасность и работоспособность

Определяется, какие компоненты обеспечивают безопасность функционирования продукта (например, модули антифрода, различные фильтры, защита от вредоносного контента и т.п.), а также критически влияют на его работоспособность в целом.

4️⃣ Возможность и скорость замены

Устанавливается, какие компоненты можно оперативно заменить аналогом или разработать самостоятельно без ущерба для продукта. Важной метрикой будет определение среднего количества человеко-часов, необходимых на написание соответствующего фрагмента кода, а также возможность, срок и стоимость приобретения аналогов с рынка.

5️⃣ Степень вклада разработчиков

Определяются компоненты, которые разрабатывались авторами, внесшими наибольший вклад в создание всей кодовой базы продукта.

Чаще всего такой вклад определяется как доля (в %) строк кода (без учета фрагментов, принадлежащих третьим лицам, включая open source, созданных ИИ и т.п.), созданных конкретным автором, от общего числа строк кодовой базы.

Также определяется доля вкладов каждого автора в создание критичных компонентов, определенных по критериям, изложенным выше.

Например, если автор с минимальным общим вкладом в продукт создал 90% одного критичного компонента, его вклад признается значимым.

Одновременно определяется «доступность»таких авторов на момент закрытия сделки, в том числе наличие с ними текущих трудовых или гражданско-правовыхе отношений.

После определения круга ключевых компонентов, авторов и процессов, в отношении них уже проводится полноценная проверка.

В то же время, нельзя исключить, что даже после такой «фильтрации» общее количество проверяемых объектов все еще будет слишком велико для целей проведения углубленного анализа. В таких случаях потребуется дальнейшее сужение выборки. ⬇️