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