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

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

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

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

Первый вопрос — что именно является объектом оценки

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

До выбора метода необходимо определить:

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

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

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

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

Поэтому необходимо разделять:

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

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

Документы о праве задают границы экономического объекта

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

Они позволяют:

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

Если объём права не установлен, даже точный финансовый расчёт может отвечать на другой вопрос.

Оценка не устанавливает юридическую действительность исключительного права

Экономический анализ использует предоставленные сведения о правах как исходную основу и не подменяет самостоятельную юридическую проверку их действительности.

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

Последствием становится ограничение предмета оценки, метода или силы результата.

Функциональность ПО — основа экономической идентификации

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

Функциональность связывает технический объект с экономической моделью:

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

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

Наличие функций не равно наличию экономического эффекта

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

Для оценки необходимо установить:

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

Количество функций само по себе не является мерой стоимости.

Более сложное ПО не обязательно стоит дороже

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

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

Простая функция может иметь существенную экономическую роль

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

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

Функциональность должна относиться к дате оценки

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

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

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

Дата оценки связывает техническое и экономическое состояние

На одну временную точку должны быть согласованы:

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

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

Объём передаваемых прав способен изменить сам предмет оценки

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

Поэтому перед расчётом необходимо понять:

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

Нельзя переносить стоимость одного объёма права на другой автоматически

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

Необходимо заново проверить:

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

Изменение права является самостоятельной причиной изменения оценочного результата.

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

Функциональность ПО может не измениться, но стоимость другого имущественного интереса всё равно потребует отдельного анализа.

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

Способ использования связывает функциональность с денежной выгодой

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

Оценщику важно понять:

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

Выручка бизнеса не является доходом ПО автоматически

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

Нельзя автоматически приписывать программному обеспечению:

• всю выручку;
• всю прибыль;
• весь рост бизнеса;
• всю экономию затрат;
• всю стоимость более широкого цифрового продукта.

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

Прибыль компании также не равна стоимости программного обеспечения

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

Оценщик должен отделить вклад:

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

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

Убыток бизнеса не доказывает нулевую стоимость ПО

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

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

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

Доходная атрибуция начинается до финансовой математики

Главный вопрос доходного подхода — не ставка и не формула дисконтирования, а происхождение экономической выгоды.

Необходимо последовательно определить:

1. какое программное обеспечение оценивается;
2. какой объём права относится к объекту;
3. какая функциональность подтверждена;
4. каким способом ПО используется;
5. какой экономический эффект создаёт соответствующая функция;
6. какие другие активы участвуют в формировании результата;
7. какая часть эффекта относится именно к оцениваемому интересу;
8. какой период такого эффекта применим на дату оценки.

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

Точная ставка не исправит неверно атрибутированный денежный поток

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

Качество причинной связи первично по отношению к точности расчёта.

Поддержка является экономически значимой характеристикой, если она подтверждена

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

Поддержка не должна учитываться абстрактно. Необходимо установить:

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

Наличие поддержки не означает автоматическую надбавку к стоимости

Сам факт поддержки не превращается в универсальный положительный коэффициент.

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

Отсутствие поддержки также не означает автоматический дисконт

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

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

Поддержка и дальнейшая разработка — не одно и то же

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

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

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

Будущая разработка не должна скрыто входить в текущую стоимость

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

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

Технологическое устаревание — отдельный оценочный фактор

Программное обеспечение может сохранять техническую работоспособность и одновременно иметь иную экономическую полезность из-за технологического изменения. Поэтому технологическое устаревание нельзя сводить только к возрасту объекта.

Оценщику необходимо определить:

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

Возраст ПО не равен технологическому устареванию

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

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

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

Отсутствие обновления не доказывает технологическое устаревание автоматически

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

Необходимо установить, как соответствующее состояние влияет на фактическую функцию ПО и экономический эффект.

Оценщик не должен подменять доказательство технологического устаревания предположением.

Наличие обновлений также не доказывает отсутствие устаревания

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

Необходимо понимать, какая функциональность существует на дату оценки и как она связана с экономическим использованием.

Технологическое устаревание и прекращение поддержки — разные факторы

Эти обстоятельства могут быть связаны, но не являются тождественными.

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

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

Технологическое устаревание и физический износ не следует смешивать

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

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

Экономический эффект устаревания должен иметь причинную связь

Если утверждается, что технологическое устаревание снижает стоимость, необходимо понимать:

1. какое изменение подтверждено;
2. какую функцию ПО оно затрагивает;
3. почему это влияет на экономическую полезность;
4. как соответствующий эффект отражается в денежном потоке или другом оценочном ориентире;
5. не учтён ли тот же эффект уже в затратах, поддержке или прогнозе.

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

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

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

Функциональность и технологическое устаревание должны анализироваться совместно

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

Поэтому профессиональная связь выглядит так:

функция → способ использования → технологическое состояние → экономическая полезность → стоимость.

Функциональное изменение может быть важнее календарного возраста

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

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

Смена версии может изменить объект сравнения

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

В такой ситуации требуется заново проверить:

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

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

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

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

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

Удалённая функциональность также не означает автоматического снижения на стоимость её создания

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

Необходимо определить, изменилась ли полезность оцениваемого имущественного интереса и каким образом.

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

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

Они сами по себе не подтверждают:

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

Большой бюджет разработки не гарантирует высокую стоимость

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

Поэтому затраты и стоимость должны быть разделены аналитически.

Небольшие затраты не ограничивают стоимость автоматически

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

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

Затраты более широкого проекта нельзя полностью приписывать ПО

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

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

Поддержка и разработка могут входить в затраты по-разному

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

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

Рыночная проверка требует сопоставимости прав и функциональности

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

Необходимо понимать:

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

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

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

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

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

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

Если критичные характеристики не раскрыты, цена получает ограниченную доказательную роль.

Недостаток прямых рыночных данных не означает отсутствие стоимости

Для программного обеспечения прямые сопоставимые рыночные данные могут быть ограничены. Это прежде всего влияет на применимость рыночной проверки.

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

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

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

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

Для этого требуется проверить:

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

Экономия затрат также требует атрибуции

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

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

Отсутствие отдельного денежного потока не означает отсутствие стоимости

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

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

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

Прямой денежный поток также требует проверки

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

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

Прогнозный период должен соответствовать экономической полезности объекта

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

Технологическое устаревание и поддержка могут быть важными элементами такой проверки.

Нельзя автоматически продолжать текущий денежный поток на неопределённый срок.

Будущий эффект не гарантируется текущей стоимостью

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

Прогнозные предпосылки должны быть отделены от подтверждённых фактов на дату оценки.

Технологическая устойчивость не должна предполагаться

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

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

Одновременно нельзя предполагать и неизбежное устаревание

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

Профессиональная модель должна оставаться нейтральной и использовать только подтверждённые факты и допустимые предпосылки.

Смешанный программный объект требует разделения компонентов

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

Сначала необходимо определить:

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

Модульная структура не означает автоматическую самостоятельность компонентов

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

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

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

Совместный эффект нескольких компонентов нельзя делить поровну

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

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

Смена одного компонента может изменить функциональность всего объекта

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

Необходимо определить, изменились ли:

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

Изменение функциональности требует новой проверки экономической модели

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

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

Это не просто количественная корректировка прежней стоимости.

Изменение объёма передаваемых прав требует новой оценки интереса

Даже при неизменной программе другой объём права может означать другой экономический объект.

Необходимо заново проверить:

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

Изменение поддержки не следует смешивать с изменением права

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

Это разные причины изменения стоимости и должны анализироваться раздельно.

Изменение технологического состояния не следует смешивать с изменением денежного потока

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

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

Изменение результата необходимо раскладывать по причинам

Между двумя датами стоимость программного обеспечения может измениться вследствие разных обстоятельств:

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

Нельзя автоматически объяснять всё изменение общим понятием устаревания.

Уточнение данных может изменить результат без изменения самого ПО

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

В таком случае изменение стоимости может отражать повышение качества доказательной базы, а не изменение программного объекта.

Как отделить функциональность от объёма права

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

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

Как отделить поддержку от функциональности

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

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

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

Отсутствие поддержки и технологическое устаревание могут иметь разные экономические причины.

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

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

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

Нельзя автоматически считать любое снижение экономического эффекта доказательством технологического устаревания.

Как отделить стоимость ПО от стоимости бизнеса

Если программное обеспечение используется внутри предприятия, стоимость бизнеса представляет более широкий экономический объект.

Необходимо определить:

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

Стоимость бизнеса и стоимость ПО нельзя складывать механически

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

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

Как отделить стоимость ПО от стоимости цифрового продукта

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

Доход всего продукта нельзя автоматически приписывать программному имущественному интересу.

Сначала необходимо определить вклад других компонентов.

Как отделить стоимость ПО от затрат на его создание

Затраты показывают использованные ресурсы. Стоимость показывает экономическую ценность конкретного имущественного интереса на дату оценки.

Эти величины могут быть связаны, но не являются взаимозаменяемыми.

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

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

Эти причины должны анализироваться отдельно.

Рыночная и доходная логики могут давать разные результаты

Расхождение не следует устранять автоматическим усреднением.

Сначала необходимо проверить:

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

Доходная и затратная модели также могут закономерно различаться

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

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

Согласование результатов должно учитывать качество доказательств

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

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

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

Перед итоговым согласованием необходимо проверить, не отражён ли один и тот же фактор одновременно:

• в денежном потоке;
• в стоимости бизнеса;
• в корректировке за поддержку;
• в корректировке за технологическое устаревание;
• в рыночной цене аналога;
• в затратах на разработку;
• в стоимости другого нематериального актива.

Двойной учёт может исказить результат как вверх, так и вниз.

Функциональность не должна учитываться дважды

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

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

Поддержка не должна учитываться дважды

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

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

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

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

Необходимо различать причину и место её отражения в модели.

Что делать, если функциональность подтверждена неполно

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

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

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

Что делать, если объём права определён неточно

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

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

Что делать, если способ использования неизвестен

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

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

Что делать, если финансовые данные относятся ко всему бизнесу

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

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

Что делать, если поддержка не подтверждена

Нельзя автоматически считать её существующей или отсутствующей.

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

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

Не следует назначать условный процент только для завершения расчёта.

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

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

Что делать, если затраты на разработку известны, а экономический эффект нет

Затратные данные могут быть полезны только в пределах применимости соответствующего метода.

Они не доказывают коммерциализацию и не создают автоматически доходную стоимость.

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

Что делать, если экономический эффект подтверждён, но затрат нет

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

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

Что делать, если прямых рыночных аналогов нет

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

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

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

Что делать, если рыночные данные относятся к другому объёму прав

Такое различие может быть фундаментальным.

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

Что делать, если программы похожи по функции, но различаются по поддержке

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

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

Что делать, если аналоги находятся в разном технологическом состоянии

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

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

Что делать, если доходный и рыночный результаты существенно расходятся

Не следует сразу усреднять их.

Необходимо проверить:

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

Что делать, если доходный и затратный результаты различаются

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

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

Что делать, если метод зависит от одного неподтверждённого коэффициента

Если без него выбранная модель не работает, это является реальным методическим ограничением.

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

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

Недостаток данных должен менять конкретную часть оценки

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

Неизвестный фактор не является автоматическим дисконтом

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

Недостаток данных сам по себе не является доказательством ухудшения объекта.

Поэтому нельзя автоматически снижать стоимость только за неполноту информации.

Неизвестность также не позволяет принять наиболее выгодный вариант

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

Оценка должна сохранять границу между фактом и предположением.

Чувствительность результата должна быть связана с центральными факторами

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

Для программного обеспечения особенно значимыми могут быть:

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

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

Ошибка в объёме права может быть важнее точности модели

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

Поэтому приоритет выглядит так:

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

Ошибка в функциональности также не исправляется коэффициентами

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

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

Сложная математика не компенсирует слабую доказательную базу

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

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

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

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

Необходимо подготовить сведения, позволяющие определить:

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

Функция документов и подготовка исходных материалов раскрываются также в разделе «Документы».

Как проверить программное обеспечение до финансового расчёта

1. Идентифицировать программный объект.
2. Определить оцениваемый имущественный интерес.
3. Зафиксировать дату оценки.
4. Проверить документы о правах.
5. Определить подтверждённую функциональность.
6. Установить объём оцениваемых или передаваемых прав.
7. Определить подтверждённый способ использования.
8. Проверить сведения о поддержке.
9. Определить данные о технологическом состоянии.
10. Выделить экономический эффект.
11. Отделить вклад других активов.
12. Только после этого выбирать оценочный метод.

Как проверить функциональность

Функциональность должна быть связана с конкретным объектом и датой оценки.

Необходимо установить:

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

Как проверить объём имущественного интереса

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

Поэтому необходимо проверить:

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

Как проверить поддержку

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

Необходимо понять:

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

Как проверить технологическое устаревание

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

1. Определить, какое изменение подтверждено.
2. Установить, какую функцию оно затрагивает.
3. Проверить влияние на способ использования.
4. Определить экономический эффект.
5. Проверить, отражён ли он в денежном потоке.
6. Исключить повторное отражение через поддержку или другие корректировки.

Как проверить финансовую атрибуцию

Финансовая модель должна отвечать на вопрос о выгоде конкретного имущественного интереса.

Следует проверить:

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

Как проверить рыночные данные

Для каждого рыночного ориентира необходимо установить:

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

Если критичные характеристики неизвестны, наличие цены само по себе не делает объект сильным аналогом.

Как проверить затратные данные

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

Проверяются:

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

Как проверить отсутствие двойного учёта

Перед согласованием результата полезно определить место каждого фактора в модели.

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

Когда доходная модель имеет сильную основу

Доходная атрибуция становится более доказательной, когда:

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

Когда доходная модель становится слабее

Существенные ограничения возникают, если:

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

В такой ситуации математическая детализация не повышает доказательность.

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

Рыночные данные становятся содержательнее, если сопоставимы:

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

Когда затратная проверка становится содержательной

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

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

Корпоративная задача не меняет объект оценки

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

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

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

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

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

Оценка строится на конкретном объекте, праве, дате и подтверждённой экономической функции.

Что должен объяснять итоговый оценочный вывод

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

Из анализа должно быть понятно:

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

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

Что оценка программного обеспечения не устанавливает

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

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

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

Где проходит граница результата

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

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

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

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