Сегодня рынок ПО в России, по данным Росстата, оценивается примерно в 530 млрд рублей в год, причем данное направление активно развивается. Это неудивительно – в связи с уходом иностранных вендоров стране нужны сотни новых программных продуктов. Для любого участника рынка вопрос оценки стоимости производимого ПО является одним из ключевых, поскольку такая информация необходима для его постановки на баланс, оценки общей стоимости активов, совершения сделок купли-продажи, при судебных спорах. В статье ниже вместе с Евгением Царевым, управляющим RTM Group, мы поговорим о том, как корректно оценивать ПО и сколько платить за частично разработанный софт.
Проблемы оценки программного обеспечения
У программного продукта, как и у любого нематериального актива, существует срок, в течение которого он приносит пользу и прибыль. После его окончания организация может оценивать актив в соответствии с ПБУ 14/2007 (или ФСБУ 14/2022, которые начнут действовать с 2024 г.). Если это предусмотрено учетной политикой, то можно проводить и плановую ежегодную переоценку. Также переоценивать можно и срок полезного использования. Но здесь есть множество разных нюансов.
Предположим, что организация заказала и купила ПО по управленческому учету за 1 млн рублей и поставила его на баланс по цене покупки и указала срок полезного использования 5 лет. По прошествии 5 лет данная программа была успешно амортизирована. При этом, продукт продолжает работать и обновляться. Тогда организация может поставить его на баланс уже по другой цене, и срок полезного использования может быть увеличен.
Другой пример: организация заказала разработку ПО для своих нужд. Но исполнитель предоставил только часть программы или ее альфа или бета –версии, которые еще не полностью могут выполнять весь заявленный функционал. Как поставить данный продукт на баланс или как оценить его стоимость в суде, если организация-исполнитель не выполнили свои договорные обязательства? Эта и многие другие ситуации выходят за рамки стандартных. Решить проблемы с оценкой ПО в «экзотических» случаях могут экспертные организации. Ну а мы постараемся подробно описать ниже, как оценить готовность ПО и его стоимость самостоятельно.
Определение уровня готовности ПО
Итак, для начала необходимо произвести оценку уровня готовности технологии (УГТ) в соответствии со стандартом ГОСТ Р 58048-2017. Данный документ позволяет определить, насколько детально разработано ПО, начиная от 1 уровня «идеи» и 9 уровня «полной готовности».
Важно отметить, что перейти на следующий уровень не получится, если не достигнуто полное соответствие для предыдущего. Приведем пример. Для 7 уровня необходимо наличие бета-версии и реализация процедуры «верификации, валидации и сертификации» (VV&A) по проверке соответствия ПО заданной спецификации, но на 6 УГТ не был завершен анализ структур баз данных и интерфейсов. Соответственно, ПО не может соответствовать ни 6, ни тем более 7 УГТ, только 5. Соответственно, и стоимость данного ПО будет достаточно низкой. Когда разобрались с уровнем готовности ПО (идеально, если будет достигнут девятый), можно переходить непосредственно к оценке.
Методы оценки стоимости ПО
Методы оценки стоимости могут помочь определить ценность продукта и решить, стоит ли вкладывать в него дополнительные ресурсы. Ниже рассмотрим три основных подхода к оценке стоимости программного обеспечения и применим их к одному и тому же ПО для управления бизнес-процессами.
Доходный подход оценки стоимости
Данный подход предполагает, что стоимость программного обеспечения определяется потенциальным доходом, который может генерировать продукт. Он обычно применяется, когда речь идет о разработке программного обеспечения, которое будет продаваться или использоваться для генерации дохода.
Один из методов доходного подхода — это метод дисконтированных денежных потоков (DDCF). Он предполагает оценку будущих доходов, которые сгенерирует ПО, и дисконтирование их настоящей стоимостью денежных средств. Другим методом является метод избыточных прибылей, который предполагает оценку будущих прибылей, которые сгенерирует ПО, и умножение их на коэффициент, который отражает ожидаемую доходность ПО. Третий метод доходного подхода — это метод рентабельности инвестиций (ROI). Он предполагает оценку ожидаемой прибыли от инвестиций в ПО и деление ее на стоимость инвестиций.
Каждый из этих методов имеет свои преимущества и недостатки, и выбор метода зависит от конкретной ситуации. Например, метод DDCF может быть полезен для оценки стоимости ПО, которое еще не вышло на рынок и не имеет установленных доходов. С другой стороны, метод избыточных прибылей может быть наиболее подходящим для оценки стоимости ПО, которое уже имеет установленные доходы.
Итак, наш пример для всех методов: разработанное компанией программное обеспечение для управления бизнес-процессами. Для оценки стоимости ПО по доходному подходу необходимо оценить платежеспособный спрос на продукт, ожидаемые доходы от продаж и затраты на разработку программного обеспечения.
Организация понимает, что ПО будет пользоваться спросом, возможно получить экономический эффект от его использования. Если назначить стоимость неисключительной лицензии в количестве 10 штук в 500 тысяч рублей, то его ожидаемая рыночная цена составит 5 млн. рублей. А вот в том случае, когда ПО предполагается использовать для собственных нужд, ожидаемый эффект будет составлять 3 млн. рублей за счет сокращения расходов времени и трудовых ресурсов. Заметная разница в стоимости зависит от выбора целей применения нематериального актива.
Однако, проблема применения данного подхода может заключаться в отсутствии достаточной информации о проекте. Например, если заказчик не предоставляет подробного описания требований к ПО, то оценка стоимости может быть некорректной или неполной.
Затратный подход оценки стоимости
Данный подход к оценке стоимости ПО основывается на затратах на его разработку. Он применяется, когда речь идет о разработке продуктов для собственного использования. Помимо тех методов, что перечислены в Федеральном стандарте оценки «Подходы и методы оценки» (ФСО V), здесь также применяются: метод прямых затрат, метод суммирования затрат на каждый этап разработки ПО, метод фактических затрат, метод экспертной оценки.
Таким образом, стоимость ПО учитывает следующие затраты:
- на оплату труда разработчиков (а именно, количество человеко-часов, затраченных на разработку ПО, и стоимость часа работы сотрудника);
- на аппаратное и программное обеспечение, необходимое для разработки ПО (компьютеры, серверы, программное обеспечение, лицензии и т. д.);
- на тестирование и внедрение ПО, а также настройку на стороне заказчика;
- на поддержку и сопровождение ПО в течение его жизненного цикла.
А теперь переходим к нашему ПО для управления бизнес-процессами. Для оценки его стоимости в данном случае будут учитываться трудозатраты на разработку технической и отчетной документации, исходного кода, настройку интеграций, проведение тестирования системы, установку и настройку ПО. Также сюда будут включены административные расходы, обязательные социальные взносы, нормы прибыли и рентабельности. Кроме того, затраты на разработку ПО могут варьироваться в зависимости от многих факторов, включая сложность проекта, опытность команды разработчиков и т. д.
Если все это наполнить некоторыми цифрами, то получается следующая картина. Так, допустим, на разработку ПО требуется 50 дней программиста уровня мидл с зарплатой 5 тыс. рублей в дней, 70 дней джуниор программиста с зарплатой 3 тыс. рублей в день, 30 дней тестировщика с зарплатой 4,5 тыс. рублей, 3,5 дня технического писателя и 20 дней руководителя проекта с зарплатой 4 тысяч рублей. Получается, что общие затраты труда составят 745 тысяч рублей. С учетом выплат по налогам и сборам, средними административными расходами, а также средней рентабельности для компаний-разработчиков стоимость ПО составляет 1,45 млн рублей.
Сравнительный подход оценки стоимости
Здесь мы сравниваем стоимость программного обеспечения с другими аналогичными продуктами на рынке. Чтобы оценить стоимость ПО в соответствии с этим подходом, можно использовать один из трех методов:
1) Метод сравнения на основе функционала ПО представляет собой определение набора схожих функций и возможностей, которые должны быть реализованы в ПО;
2) Метод сравнения на основе объема (например, количество строк кода или количество функций);
3) Метод сравнения на основе рыночной ценовой информации об объектах-аналогах.
Конечно, этот подход имеет и недостатки, но явным его преимуществом является простота. Если прибегнуть к нему и найти подходящие аналоги, можно довольно оперативно оценить стоимость ПО. Единственное – не всегда достаточно информации, чтобы сделать корректные выводы.
Итак, предположим, что для нашего ПО для управления бизнес-процессами найден аналог со схожим функционалом. Известно, что его рыночная стоимость составляет 2,5 млн рублей. Сравнив функционал и особенности ПО, мы приходим к выводу, что совпадение составляет 0,85 к 1 у аналога. Таким образом, стоимость ПО — объекта исследования не может превышать 2,125 млн. рублей.
Итак, как мы видим из расчетов выше, каждый раз у нас получается разная стоимость продукта, которая зависит от методов оценки. Различаются они довольно сильно — от 1,45 до 5 млн. рублей. Однако, необходимо учитывать, что стоимость продукта на рынке не может быть одинаковой в момент его появления (когда имеет смысл учитывать лишь основные затраты) и через год, когда он уже известен и имеет определенную репутацию, круг пользователей и т. д. Именно поэтому выбор подхода должен быть обоснован в процессе оценки.
Проверка (экспертиза) оценки стоимости
Чаще всего вопрос оценки стоимости ПО возникает при разрешении споров по ИТ-контрактам. Тогда компании (или же суды) обращаются к экспертам, чтобы узнать, какова стоимость фактически выполненных работ по разработке программного обеспечения, указанного в договоре. Назначается компьютерно-техническая или оценочная (стоимостная) судебная экспертиза. В свою очередь, эксперты для исследований применяют различные методы проверки ПО, включая методы статического и динамического анализа программного кода.
Для того, чтобы оценить стоимость частично разработанного ПО, можно прибегнуть к применению частных методик, например, к экспертной оценке трудозатрат, включающей в себя выявление затраченного объема на разработку в часах, а также стоимости одного человека-часа сотрудника. Данный подход схож с затратным методом оценки. В любом случае, какой бы метод вы ни выбрали для оценки частично разработанного ПО, важно учитывать его готовность, а также примерные расходы на доведение продукта до статуса готового.