Как видно из графиков, риски, связанные с титулом ПО, являются самыми распространенными (88% респондентов), а также самыми критичными (95% респондентов).
Это не значит, что кроме ПО в ИТ-проектах все остальное второстепенно. Но ПО (особенно в продуктовых бизнесах) является ценнобразующим активом номер один. Особенно, если у него уже есть рынок и сохраняется потенциал роста.
Даже в относительно небольших проектах (3-5 лет) проектах в рамках продукта могут существовать десятки крупных проприетарных компонентов (подсистем, модулей), особенно в тех, что имеют архитектуру супераппов. В том числе в прод-версии.
Что делать с проверкой такого продукта? Проверять все сплошняком по принципу «что дадут, то и проверим» — не эффективно. ПО тоже нужно проверять осознанно (простите 😃). Иначе может получиться ситуация, когда проверили то, что легко переписать / заменить, но оставили без внимания то, что было действительно важно.
Как понять, что в продукте важно / критично (это решают не юристы)?
Для этого можно использовать подход архитектурной декомпозиции продукта, что позволит сузить периметр проверки до наиболее значимых объектов и процессов.
Классифицировать ОИС в составе продукта по степени их существенности для бизнеса может техническая и операционная команда компании с учетом позиции приобретателя бизнеса, его планов по интеграции и стратегического развития продукта.
💠💠💠
При определения порога материальности соответствующих компонентов продукта, чаще всего учитывается комплекс критериев, в частности:
1️⃣Влияние на финансовый результат
Определяется, на какие функциональные компоненты продукта прямо или косвенно приходится наибольшая доля выручки, какие из них обеспечивают существенную экономию на расходах, а также могут быть комплементарны продуктам приобретаемой компании и обеспечить реализацию синергий.
2️⃣ Функциональность
Оценивается, какие компоненты IT-решения носят системообразующий характер и составляют его функциональное ядро, а какие представляют собой дополнительные опции, в том числе подключаемые бесплатно.
Также могут использоваться метрики юнит-экономики, показывающие наибольшую LTV отдельных функций, метрики динамики оттока клиентов и отказа от использования продукта в целом при отключении отдельных пакетов функционала.
3️⃣ Безопасность и работоспособность
Определяется, какие компоненты обеспечивают безопасность функционирования продукта (например, модули антифрода, различные фильтры, защита от вредоносного контента и т.п.), а также критически влияют на его работоспособность в целом.
4️⃣ Возможность и скорость замены
Устанавливается, какие компоненты можно оперативно заменить аналогом или разработать самостоятельно без ущерба для продукта. Важной метрикой будет определение среднего количества человеко-часов, необходимых на написание соответствующего фрагмента кода, а также возможность, срок и стоимость приобретения аналогов с рынка.
5️⃣ Степень вклада разработчиков
Определяются компоненты, которые разрабатывались авторами, внесшими наибольший вклад в создание всей кодовой базы продукта.
Чаще всего такой вклад определяется как доля (в %) строк кода (без учета фрагментов, принадлежащих третьим лицам, включая open source, созданных ИИ и т.п.), созданных конкретным автором, от общего числа строк кодовой базы.
Также определяется доля вкладов каждого автора в создание критичных компонентов, определенных по критериям, изложенным выше.
Например, если автор с минимальным общим вкладом в продукт создал 90% одного критичного компонента, его вклад признается значимым.
Одновременно определяется «доступность»таких авторов на момент закрытия сделки, в том числе наличие с ними текущих трудовых или гражданско-правовыхе отношений.
После определения круга ключевых компонентов, авторов и процессов, в отношении них уже проводится полноценная проверка.
В то же время, нельзя исключить, что даже после такой «фильтрации» общее количество проверяемых объектов все еще будет слишком велико для целей проведения углубленного анализа. В таких случаях потребуется дальнейшее сужение выборки. ⬇️
