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

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

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

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

В зависимости от исходных документов предмет может включать:

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

Эти варианты нельзя смешивать. Стоимость всей системы не должна автоматически переноситься на один модуль, а стоимость отдельного компонента — на весь программный комплекс.

Права на код необходимо отделить от самого факта существования программы

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

Поэтому специалист сопоставляет:

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

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

Наличие исходного кода и право на него — разные вопросы

Физический или технический доступ к исходному коду сам по себе не определяет объём имущественных прав.

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

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

Почему функциональный объём критичен для стоимости

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

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

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

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

Большой перечень возможностей не означает автоматически высокой экономической ценности.

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

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

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

Количество строк кода, файлов или технических компонентов не является самостоятельной мерой стоимости.

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

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

Стадия жизненного цикла меняет саму оценочную задачу

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

Поэтому необходимо определить, в каком состоянии находится продукт на дату оценки:

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

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

Незавершённая разработка не равна готовому программному продукту

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

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

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

Работающий продукт не означает завершение жизненного цикла

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

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

Это различие важно и для затратного, и для доходного анализа.

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

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

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

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

Показатель должен использоваться только тогда, когда его связь со стоимостью обоснована.

Зарегистрированные и активные пользователи не должны смешиваться

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

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

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

Внутреннее ПО и коммерческий программный продукт создают выгоду по-разному

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

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

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

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

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

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

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

Доход компании не равен доходу программного обеспечения

Программный продукт функционирует в составе более широкой бизнес-системы.

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

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

Экономия может быть экономическим эффектом внутренней системы

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

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

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

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

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

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

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

Затраты поддержки напрямую влияют на экономическую ценность

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

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

Необходимо понимать, какие расходы относятся к:

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

Границы этих категорий должны следовать из представленных данных.

Поддержка и новая разработка — разные экономические процессы

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

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

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

Доходный подход строится через относимую выгоду

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

Расчёт должен отвечать на вопросы:

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

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

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

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

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

Стадия жизненного цикла должна согласовываться с прогнозом

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

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

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

Устаревание ПО может быть функциональным и экономическим

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

При этом возраст программы сам по себе не доказывает устаревание.

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

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

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

Оценка должна исходить из фактической полезности и жизненного цикла.

Новая система также не обязательно имеет высокую стоимость

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

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

Заменяемость программного актива влияет на модель

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

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

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

Альтернативное ПО нельзя сравнивать только по цене лицензии

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

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

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

Лицензионная логика возможна при сопоставимых данных

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

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

Сопоставимость требует анализа:

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

Одна лицензионная ставка не является готовой стоимостью

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

Оценщик должен понять, насколько эти отношения сопоставимы с оцениваемым имущественным интересом.

Механический перенос процента или платежа без анализа условий создаёт ложную точность.

Внутригрупповая лицензия требует отдельной проверки

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

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

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

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

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

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

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

Почему затраты разработки не равны стоимости

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

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

Поэтому между исторической себестоимостью и текущей стоимостью нет автоматического равенства.

Оплата труда разработчиков — только часть затратной картины

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

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

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

Нельзя оценивать ПО только через человеко-часы

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

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

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

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

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

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

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

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

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

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

Такие факторы учитываются только в подтверждённой части.

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

Стоимостный анализ не является аудитом информационной безопасности.

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

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

Оценка не подтверждает качество кода

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

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

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

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

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

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

Внешние библиотеки и компоненты требуют разграничения в объекте

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

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

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

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

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

Простой подсчёт модулей не решает этот вопрос.

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

Как избежать двойного счёта между модулями

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

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

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

Как избежать двойного счёта между методами

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

Полученные величины нельзя просто сложить.

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

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

Качество методов может существенно различаться.

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

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

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

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

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

Но эффект необходимо доказать, а не предположить из факта автоматизации.

Что делать, если есть пользователи, но нет выручки

Количество пользователей показывает использование, но не формирует стоимость автоматически.

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

Без такой связи число пользователей остаётся описательным показателем.

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

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

До начала оценки необходимо определить объект и подтверждённый объём прав.

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

Что делать, если разработка велась несколькими лицами

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

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

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

Что делать, если функциональный объём не документирован

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

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

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

Что делать, если продукт находится в активной разработке

Необходимо разделить существующую на дату оценки функциональность и будущие возможности.

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

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

Что делать, если продукт постепенно выводится из эксплуатации

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

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

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

Что делать, если затраты поддержки быстро растут

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

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

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

Что делать, если существует более дешёвая альтернатива

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

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

Только после этого можно анализировать влияние заменяемости на стоимость.

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

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

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

Что делать, если ПО невозможно отделить от соседних активов

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

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

Недостаточность информации должна стать ограничением результата.

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

Профессиональная последовательность может быть следующей:

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

При недостатке данных должен меняться метод, а не факты

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

В зависимости от характера пробела специалист может:

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

Какие документы подготовить

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

Полезно подготовить:

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

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

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

Документы о праве отвечают на вопрос, какой имущественный интерес оценивается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где проходит граница оценочного вывода

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

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

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

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

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

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

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

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