Программное обеспечение
Программное обеспечение оценивают как функциональный продукт и одновременно как набор прав. Поэтому стоимость нельзя надёжно определить только по затратам на разработку, объёму кода или текущей выручке продукта. Необходимо установить, какие права на код входят в объект оценки, как программное обеспечение монетизируется и какие затраты поддержки и технологическое устаревание ограничивают его экономическую полезность.
Основная профессиональная модель сочетает доходную оценку программного обеспечения и стоимость воспроизводства его функционала. Сначала оценщик идентифицирует объект, состав оцениваемого права и дату оценки, изучает документы о происхождении или правовой охране, договоры использования и финансовые данные. Затем анализируются состав прав на код, модель монетизации, затраты поддержки и технологическое устаревание. Только после этого определяется, какая часть стоимости объясняется экономическим эффектом использования ПО, а какая может быть проверена через воспроизводство его функционала.
Сначала необходимо определить, что именно входит в объект оценки
Программное обеспечение может рассматриваться как единый продукт, но его экономическая стоимость зависит от состава прав, которые действительно принадлежат оцениваемому имущественному интересу.
Документы о происхождении или правовой охране используются для идентификации объекта и состава права. Договоры использования помогают установить, каким образом программный продукт вовлечён в экономическую деятельность.
Если границы права не определены, расчёт может фактически относиться к функционалу, который не входит в оцениваемый объект.
Состав прав на код определяет границы экономической стоимости
Для оценки необходимо установить, какие права на программный код входят в объект и в каком объёме они могут использоваться в рассматриваемой экономической модели.
Нельзя автоматически считать, что весь используемый функционал принадлежит одному правообладателю или входит в один оцениваемый актив. Сначала определяется подтверждённый состав права, затем к нему привязывается экономический эффект.
Чем точнее определены границы права, тем надёжнее доходная и затратная модели описывают один и тот же объект.
Программный продукт и права на него необходимо различать
Функционально работающий продукт и имущественное право на его код — связанные, но не тождественные понятия.
Оценка должна отвечать на вопрос о стоимости конкретно идентифицированного имущественного интереса. Поэтому экономический эффект от продукта нельзя автоматически полностью приписывать оцениваемому праву, если часть соответствующего функционала или условий использования относится к иным компонентам.
Это особенно важно при смешанных объектах, где программный продукт включает несколько самостоятельных прав или функциональных частей.
Доходная модель строится вокруг подтверждённой модели монетизации
Программное обеспечение может создавать экономический эффект только в той модели использования, которая подтверждается исходными данными.
Поэтому оценщик должен установить, как именно продукт связан с получением дохода или иным финансовым результатом. Финансовые данные должны описывать экономический эффект конкретного программного обеспечения, а не бизнеса в целом.
Без такой связи даже подробная финансовая отчётность не создаёт надёжную доходную модель.
Модель монетизации определяет, какие финансовые данные релевантны
Если экономический эффект продукта формируется через определённый способ использования, именно к нему должны относиться показатели дохода, затрат и иных финансовых результатов.
Нельзя смешивать разные модели монетизации без объяснения того, какую функцию каждая из них выполняет в расчёте.
Доходная модель должна отражать фактическую экономическую связь между правом на программное обеспечение и результатом его использования.
Выручка продукта не равна автоматически стоимости программного обеспечения
Даже если программный продукт формирует доход, эта выручка может зависеть не только от кода, но и от других ресурсов бизнеса.
Поэтому оценщик должен определить, какая часть экономического эффекта действительно относится к оцениваемому программному обеспечению и правам на него.
Нельзя автоматически капитализировать всю выручку продукта как стоимость кода.
Доход бизнеса и доход от программного обеспечения необходимо разграничивать
Организация может использовать программный продукт вместе с персоналом, инфраструктурой, клиентской базой и другими активами.
Если весь финансовый результат приписать программному обеспечению, стоимость объекта будет включать экономический эффект других компонентов.
Поэтому доходная модель требует отдельного обоснования вклада именно оцениваемого программного продукта.
Исторический доход не является гарантией будущего эффекта
Прошлые финансовые показатели помогают понять экономическую историю продукта, но стоимость относится к установленной дате оценки.
Нельзя автоматически переносить исторический доход на будущий период без учёта текущей модели монетизации, затрат поддержки и технологического состояния программного обеспечения.
Оценка не является гарантированным прогнозом коммерческого результата.
Стоимость воспроизводства функционала отвечает на другой вопрос
Затратная логика используется для проверки того, сколько ресурсов экономически необходимо для воспроизведения сопоставимого функционального результата.
При этом воспроизводится не обязательно исходный код в буквальном виде. Центральным является функционал, который обеспечивает экономическую полезность продукта.
Такой подход помогает отделить текущую экономическую ценность функции от исторических затрат на первоначальную разработку.
Исторические затраты на разработку не равны текущей стоимости
Расходы на создание программного обеспечения показывают, сколько ресурсов было затрачено в прошлом.
Но часть разработки могла утратить экономическую актуальность, а часть функционала могла, наоборот, сохранять существенную полезность независимо от первоначальной стоимости его создания.
Поэтому понесённые затраты являются исходной информацией, но не готовым результатом оценки.
Стоимость воспроизводства функционала не должна повторять неэффективные затраты прошлого
Если тот же экономический результат можно воспроизвести иным способом, затратная проверка должна отражать функциональную задачу, а не буквально копировать исторический процесс разработки.
Иначе в расчёт могут попасть расходы, не необходимые для получения сопоставимого программного продукта.
Профессиональная модель поэтому ориентируется на воспроизводство функции, а не на механическое повторение всех прошлых работ.
Доходная и затратная модели должны описывать один объект
Если доходная модель относится к определённому программному функционалу и набору прав, затратная проверка должна воспроизводить именно этот же функциональный объём.
Нельзя сравнивать доход от полного программного продукта со стоимостью воспроизводства только части кода без отдельного объяснения.
Согласование начинается с идентичности объекта, а не с усреднения двух полученных величин.
Модель монетизации может объяснять стоимость сильнее объёма разработки
Большой объём кода или длительный период разработки не обязательно означают высокую экономическую стоимость.
Если программное обеспечение имеет подтверждённую модель монетизации и создаёт экономический эффект, именно эта функция может быть центральной для доходной оценки.
В другой ситуации затраты на создание могут быть значительными, но экономический эффект использования — недостаточно подтверждённым.
Затраты поддержки являются частью экономической модели
Программное обеспечение может требовать постоянных затрат для сохранения работоспособности и экономической функции.
Поэтому доход от продукта нельзя рассматривать изолированно от расходов, необходимых для его поддержки в рассматриваемой модели использования.
Если такие затраты materially влияют на экономический эффект, они должны быть учтены в модели и подтверждены исходными данными.
Поддержка не равна разработке
Расходы на поддержку относятся к сохранению или обеспечению текущей функции программного продукта, тогда как разработка создаёт или изменяет функционал.
Смешение этих затрат может исказить как доходную модель, так и расчёт стоимости воспроизводства.
Поэтому оценщик должен понимать экономическую роль соответствующих расходов и не учитывать один и тот же эффект дважды.
Высокие затраты поддержки могут ограничивать экономическую стоимость
Если поддержание программного продукта требует значительных подтверждённых расходов, это может уменьшать экономический эффект от его использования.
В такой ситуации высокая выручка сама по себе не означает высокой стоимости программного обеспечения.
Необходимо анализировать результат после учёта расходов, непосредственно связанных с сохранением оцениваемой функции.
Технологическое устаревание влияет на функциональную полезность
Программное обеспечение оценивается не только через то, что оно способно выполнять формально, но и через экономическую актуальность соответствующего функционала на дату оценки.
Если технологическое состояние объекта ограничивает дальнейшее использование или увеличивает затраты поддержки, это materially влияет на профессиональную модель.
Такое устаревание должно быть связано с подтверждёнными особенностями объекта, а не назначаться произвольно только по возрасту программы.
Возраст программного продукта не равен технологическому устареванию
Календарный возраст сам по себе не показывает, насколько программное обеспечение экономически актуально.
Один продукт может сохранять функцию при значительном возрасте, другой — требовать существенной поддержки или обновления значительно раньше.
Поэтому оценщик анализирует фактические затраты поддержки и подтверждённое технологическое состояние, а не применяет универсальный коэффициент по возрасту.
Технологическое устаревание нельзя учитывать дважды
Если повышенные затраты поддержки уже отражают экономические последствия устаревания, дополнительное полное снижение стоимости по тому же основанию может привести к двойному счёту.
Аналогично, если стоимость воспроизводства функционала уже предполагает более рациональную современную реализацию, часть технологической разницы может быть учтена самой моделью замещения.
Перед согласованием необходимо определить, где именно отражён соответствующий фактор.
Модель монетизации и технологическое состояние взаимосвязаны
Одна и та же функциональность может иметь различную экономическую ценность в зависимости от того, насколько устойчиво программное обеспечение поддерживает выбранную модель использования.
Если поддержка становится materially более затратной или технологическое состояние ограничивает применение продукта, доходная модель должна учитывать это влияние.
Поэтому экономический эффект нельзя рассматривать отдельно от способности программного обеспечения сохранять свою функцию.
Состав прав может быть главным ограничением стоимости
Даже при наличии подтверждённой выручки и функционально сильного продукта стоимость должна относиться только к тому объёму прав, который входит в объект оценки.
Если права на существенную часть кода или функционала не входят в оцениваемый имущественный интерес, соответствующий экономический эффект нельзя полностью приписывать объекту.
В такой ситуации границы права способны ограничивать стоимость сильнее финансового результата.
Модель монетизации может быть главным фактором при ясном составе прав
Если объект права определён и функционал подтверждён, центральным вопросом становится способность программного обеспечения создавать экономический эффект.
Тогда финансовая модель может дать основное объяснение стоимости, а затраты воспроизводства используются как дополнительная проверка.
Но такой вывод возможен только при доказанной связи между продуктом и соответствующей монетизацией.
Затраты поддержки и устаревание могут ограничивать стоимость сильнее дохода
Высокий текущий доход не устраняет экономические последствия дорогостоящей поддержки или технологических ограничений.
Если сохранение функционала требует materially значимых расходов, они должны уменьшать экономический эффект, относящийся к объекту.
Поэтому оценщик сопоставляет альтернативные объяснения стоимости, а не принимает выручку как единственный драйвер.
Смешанный программный продукт необходимо разделять по правам и функциям
Если продукт включает несколько самостоятельных программных компонентов или прав, необходимо определить, какие из них входят в объект оценки и какую экономическую функцию выполняет каждый компонент.
Нельзя полностью приписывать одному праву доход, создаваемый совместной работой нескольких самостоятельных элементов.
Сначала разграничиваются компоненты, затем исключается двойной счёт их экономического эффекта.
Один и тот же функционал нельзя учитывать дважды
Если определённая функция уже полностью отражена в доходной модели продукта, её нельзя повторно прибавлять как самостоятельный актив без отдельного основания.
Аналогично при расчёте стоимости воспроизводства необходимо исключить повторное включение одного и того же функционального компонента.
Каждый экономический эффект должен иметь одно место в модели.
Если состав прав на код не подтверждён, объект оценки остаётся неопределённым
Без понимания того, какие права входят в оцениваемый имущественный интерес, невозможно надёжно связать с объектом доход или стоимость воспроизводства функционала.
Нельзя автоматически считать, что весь используемый код принадлежит одному правообладателю или входит в оцениваемый объект.
Такой пробел является фундаментальным ограничением результата.
Если модель монетизации не установлена, доходная оценка теряет основу
Без понимания того, как программное обеспечение создаёт экономический эффект, финансовые данные не могут быть корректно связаны с объектом.
Оценщик не должен подставлять условную модель использования только для завершения расчёта.
В такой ситуации доходная часть результата становится менее доказательной.
Если затраты поддержки неизвестны, экономический эффект может быть завышен
Доход без анализа расходов, необходимых для сохранения функционала, может давать неполную картину экономической полезности программного продукта.
Если соответствующие данные отсутствуют, нельзя автоматически считать поддержку несущественной.
Недостаток информации должен быть раскрыт как источник неопределённости.
Если технологическое устаревание не подтверждено, нельзя назначать произвольное снижение
Возраст программы или субъективная оценка её современности не являются достаточным основанием для числовой корректировки.
Экономические последствия устаревания должны проявляться через подтверждённые характеристики продукта, затраты поддержки или иные данные, относящиеся к его функции.
Если таких сведений нет, фактор остаётся неопределённым, а не заменяется условным коэффициентом.
Документы должны описывать один программный продукт и один набор прав
Для профессиональной оценки необходима согласованная исходная база:
- документы о правовой охране или происхождении права — для идентификации программного обеспечения и состава оцениваемого права;
- сведения о составе прав на код — для определения границ объекта;
- лицензионные или иные договоры использования — для подтверждения экономической модели использования продукта;
- финансовые данные об экономическом эффекте — для построения доходной модели;
- сведения о модели монетизации — для связи программного обеспечения с доходом или иным результатом;
- данные о затратах поддержки — для определения экономической нагрузки сохранения функционала;
- сведения о технологическом состоянии — если они materially влияют на полезность или затраты;
- дату оценки и состав права — чтобы все документы и расчёты относились к одному объекту и временному состоянию.
Практическая роль исходных материалов и их подготовка раскрыты в разделе «Документы».
Противоречия между документами нельзя разрешать в пользу более высокой стоимости
Если документы о правах, договоры использования и финансовые данные описывают программный продукт по-разному, сначала необходимо определить подтверждённые характеристики.
Нельзя выбирать более широкий состав прав, более выгодную модель монетизации или меньшие затраты поддержки только потому, что они увеличивают итог.
Неустранённое расхождение должно оставаться видимым как ограничение результата.
Для корпоративных задач важно не смешивать стоимость ПО со стоимостью бизнеса
Если результат используется в рамках корпоративных задач, необходимо определить, оценивается ли конкретный программный продукт и набор прав или более широкий имущественный комплекс.
Доход бизнеса нельзя автоматически полностью приписывать программному обеспечению. Сначала устанавливается экономическая функция ПО и границы права, затем к ним привязывается соответствующий финансовый эффект.
Назначение отчёта определяет область использования результата, но не меняет состав оцениваемого объекта.
Оценка не устанавливает действительность правовой охраны или факт нарушения права
Стоимостной вывод относится к экономической ценности идентифицированного программного обеспечения и набора прав в пределах предоставленных исходных данных.
Оценщик не устанавливает самостоятельно действительность правовой охраны и не определяет наличие нарушения права.
Если такие вопросы materially влияют на объект, они должны быть разрешены соответствующим способом за пределами оценочной модели.
Оценка не гарантирует будущий коммерческий эффект программного продукта
Даже подтверждённая модель монетизации и исторические финансовые результаты не означают, что такой же доход будет получен в будущем.
Оценочная модель отражает экономическую стоимость на установленную дату и опирается на подтверждённые исходные данные, включая затраты поддержки и технологическое состояние.
Чем слабее подтверждена связь между программным продуктом и экономическим эффектом, тем выше неопределённость результата.
Итог должен объяснять стоимость функционального продукта и принадлежащих на него прав
После идентификации программного обеспечения и состава оцениваемого права, проверки модели монетизации, финансового эффекта, затрат поддержки и технологического устаревания оценщик формирует доходную модель и сопоставляет её с затратами на воспроизводство соответствующего функционала.
Доходная часть должна показывать, какой экономический результат относится именно к оцениваемому программному обеспечению. Затратная проверка должна описывать воспроизводство того же функционального объёма и не включать избыточные или повторно учтённые компоненты.
Итоговая величина или диапазон формируются только после фактического расчёта. Нельзя определить стоимость программного обеспечения только по количеству строк кода, затратам на разработку, общей выручке бизнеса или стоимости создания продукта в прошлом.
Наиболее устойчив вывод, когда документально подтверждены состав прав на код, модель монетизации, экономический эффект, затраты поддержки, технологическое состояние, состав оцениваемого права и дата оценки. При неполноте этих сведений раскрывается повышенная неопределённость.
Результат относится к экономической стоимости конкретно идентифицированного программного продукта и набора прав на него. Он не устанавливает действительность правовой охраны, факт нарушения права и не гарантирует коммерческий эффект.
Другие виды имущества и имущественных прав представлены в разделе «Оценка».