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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти обстоятельства могут влиять на стоимость несколькими способами.

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

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

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

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

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

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

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

Программный продукт, продаваемый клиентам

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

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

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

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

Внутренняя корпоративная система

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

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

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

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

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

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

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

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

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

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

Лицензионные платежи и подписки

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

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

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

Удержание пользователей

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

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

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

Расходы на поддержку и развитие

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

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

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

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

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

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

Когда применяется затратный подход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важны следующие различия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как оценивается программный продукт при отсутствии продаж

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

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

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

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

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

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

Результат оценки и его использование

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

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

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

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

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

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

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

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

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

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

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