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

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

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

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

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

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

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

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

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

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

Стоимость программного обеспечения не равна стоимости бизнеса

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

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

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

Функциональность определяет, что именно создаёт экономическую полезность

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

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

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

Стадия использования влияет на выбор модели

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

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

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

Затраты на разработку и стоимость ПО отвечают на разные вопросы

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

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

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

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

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

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

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

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

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

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

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

Лицензионная модель требует подтверждённой договорной основы

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

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

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

Лицензия и право на программное обеспечение могут иметь разные границы

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

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

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

Экономия от использования требует доказанной связи с ПО

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

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

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

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

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

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

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

Поддержка и дальнейшее использование влияют на интерпретацию результата

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

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

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

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

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

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

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

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

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

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

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

Документы о правах подтверждают объект оценки

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

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

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

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

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

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

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

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

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

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

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

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

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

Высокая или низкая стоимость также не доказывает качество кода автоматически.

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

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

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

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

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

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

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

Что означает итоговая стоимость программного обеспечения

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

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

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

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

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