Программное обеспечение

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

Что именно оценивается: программа или права на неё

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

Важно различать исключительное право на программу и право её использования по лицензии. При передаче исключительного права и предоставлении ограниченного разрешения на использование покупатель или лицензиат получает разный объём возможностей. Поэтому стоимость полного объёма прав нельзя автоматически приравнивать к стоимости отдельной лицензии.

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

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

Какие документы необходимы для оценки программного обеспечения

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

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

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

Если документы о создании программы или условиях использования библиотек отсутствуют, оценщик должен отделить подтверждённые обстоятельства от допущений — специально обозначенных предположений, используемых при расчёте. Неустановленные права нельзя без обоснования считать принадлежащими владельцу программного продукта.

Как определяется рыночная стоимость программного обеспечения

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

Доходный подход: подписка и лицензии

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

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

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

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

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

Затратный подход: стоимость замещения программы

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

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

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

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

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

Внутренняя корпоративная система и тиражируемый продукт: почему расчёт различается

Рассмотрим две ситуации с принципиально разными источниками экономической выгоды.

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

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

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

Однако наличие подписной выручки не означает, что все поступления будут сохраняться в будущем. Продукт нуждается в обновлениях, поддержке и удержании пользователей. Эти расходы и неопределённость будущих платежей необходимо учитывать при определении стоимости.

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

Почему ограничения на библиотеки и устаревшая архитектура влияют на стоимость

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

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

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

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

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

Результат оценки и его применение

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

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

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

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

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