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

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

Сначала определяется не программа вообще, а оцениваемое право

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

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

Права на ПО и программный код — не одно и то же

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

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

Функциональность определяет экономическую полезность продукта

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

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

Технические сведения нужны для понимания объекта, а не для подмены стоимости

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

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

Выручка продукта не равна стоимости программного обеспечения

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

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

Экономия также может формировать ценность

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

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

Доходная модель требует отделить эффект ПО от бизнеса в целом

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

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

Лицензионные договоры могут дать прямой ориентир использования права

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

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

Фактический лицензионный поток нужно отделять от потенциального

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

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

Затраты разработки могут использоваться только по своей функции

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

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

Стоимость воспроизведения не равна историческим расходам

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

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

Технологическое устаревание способно изменить стоимость

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

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

Разработка и действующий программный продукт — разные стадии

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

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

Программное обеспечение и бизнес нельзя оценивать как один объект

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

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

Код, права и коммерческая модель нужно разграничивать

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

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

Нельзя дважды учитывать один и тот же экономический эффект

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

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

Статья о ПО помогает разграничить права и доходы

При оценке программного продукта особенно важно понять, что именно является активом и какие денежные потоки относятся к нему. Эта логика подробнее раскрыта в материале «Программное обеспечение как актив: какие права и доходы важны для оценки».

При сделке состав передаваемых прав должен совпадать с предметом оценки

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

Контекст использования оценки при передаче актива дополнительно раскрыт в разделе «Сделка».

В корпоративных задачах важно отделять ПО от стоимости всей компании

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

Дополнительный контекст применения результата представлен в разделе «Корпоративные задачи».

Дата оценки фиксирует права, функциональность и экономику использования

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

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

Что происходит при недостатке исходных данных

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

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

Как интерпретировать итоговую стоимость программного обеспечения

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

Оценка не устанавливает юридическую действительность прав и не подтверждает отсутствие нарушений прав третьих лиц. Центральный профессиональный вопрос — определить ценность прав на программное обеспечение отдельно от самого кода и действующего бизнеса. Другие виды имущества и прав представлены в разделе «Оценка».

Предварительно разберём документы и задачу проверки

Пришлите документы — определим, что нужно проверить и в каком объёме

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