Капитальные и операционные расходы — рецепт от SAFe®

Вольный перевод статьи CapEx and OpEx – Scaled Agile Framework.

Лидерам, отвечающим за Lean-Agile-трансформации в компаниях, нужно понимать текущую практику оценки стоимости разработки программного обеспечения, а также то, как применять эти принципы в Agile-разработке. Иначе Agile-трансформация может быть заблокирована или наоборот, компания не сможет правильно учитывать расходы на разработку. — SAFe

Примечание: Статья является частью расширенного руководства SAFe, но к ней нельзя получить доступ непосредственно с SAFe Big Picture.

Капитальные затраты (Capital Expenses, CapEx) и операционные расходы (Operating Expenses, OpEx) описывают методы Lean-Agile по финансовому учету бюджета Value Stream (потока поставки ценности). В некоторых случаях CapEx может включать результат работы, связанный с разработкой нематериальных активов, таких как программное обеспечение (ПО), интеллектуальная собственность и патенты.

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

Хотя практика капитализации ПО хорошо зарекомендовала себя во многих предприятиях, она, как правило, основана на каскадном подходе (waterfall), в котором предварительные этапы сбора требований и проектирования могут использоваться для учета затрат. Но в Agile-разработке нет таких этапов.

Компании столкнулись с новой проблемой: как эффективно учитывать эти затраты, работая по Agile. Если финансовый отдел не сможет согласовать изменение методологии, возможно, придется продолжить работу в рамках каскадной разработки. Или он может принять решение о включении всех трудозатрат в рамках Agile-разработки в OpEx. Ни один из этих подходов не идеален.

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

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

Работающие в соответствии с SAFe компании финансируют портфель для поддержки разработки и управления набором решений. В рамках портфеля за распределение средств по отдельным потокам поставки ценности отвечает Lean Portfolio Management (LPM), который выделяет необходимое финансирование для каждого потока поставки ценности в портфеле. Бюджет портфеля в SAFe может включать элементы как CapEx, так и OpEx. К OpEx относят текущие затраты на эксплуатацию продукта, бизнеса или услуги, включая:

• Заработную плату.
• Работу операционного блока, продаж и маркетинга.
• Общие и административные расходы.
• Обучение.
• Техническую поддержку.
• Аренду.
• Другие расходы, связанные с ведением .бизнеса

Затраты отражаются и относятся к OpEx в том периоде, в котором они возникли. Чаще всего CapEx отражает денежные средства, необходимые для покупки, модернизации или ремонта материальных активов, таких как сервера, персональные компьютеры или другое оборудование. В этом случае стоимость покупки указывается в балансе как актив, а затем списывается на расходы в отчете о прибылях и убытках (Profit and Loss, P&L) в течение срока полезного использования этого актива.

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

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

Учет затрат на разработку программного обеспечения

Правила капитализации программных активов различаются в зависимости от страны и отрасли. В России РСБУ (Российские стандарты бухгалтерского учёта) являются обязательными стандартами финансовой отчетности РФ и предоставляют рекомендации по общепринятым принципам бухгалтерского учета для российских компаний, которые представляют финансовую отчетность в первую очередь для регуляторов, а затем и в общественных интересах. В свою очередь РСБУ состоит из ПБУ (положений по бухгалтерскому учёту) и норм ФЗ.

Учет затрат на разработку программного обеспечения необходимо вести согласно положению 14/2007 «Учёт нематериальных активов», а также руководствуясь статьями ГК 1295 и 1296. Также уже принят ФСБУ (Федеральный стандарт бухгалтерского учета) 14/2022 «НЕМАТЕРИАЛЬНЫЕ АКТИВЫ», его обязаны применять с 2024 года, но организация вправе применять его с 2023 года. ФСБУ — переведенные и адаптированные нормы МСФО (Международные стандарты финансовой отчетности).

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

РСБУ устанавливает, что затраты внутри компании при создании компьютерного программного продукта, должны относиться на расходы до тех пор, пока они идут на исследования и разработки, пока не будет доказана (проверена) их технологическая осуществимость.

© Чернушенко Зоя Владимировна, главный бухгалтер группы Mango Office

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

Классификация программного обеспечения согласно РСБУ

В соответствии с РСБУ существует три основных классификации разработки ПО:

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

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

Капитализация по сравнению с критериями расходов

В целом, РСБУ требует, чтобы продукт соответствовал следующим критериям для капитализации текущих затрат на разработку:

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

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

Таблица 1. Категории списанных и потенциально капитализированных затрат

Капитализация в каскадной разработке

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

Рисунок 1. Ранние каскадные этапы устанавливают осуществимость и приводят к принятию руководством обязательства по финансированию

Стратегии капитализации Agile-разработки в SAFe

Однако, в Agile требования и архитектура прорабатываются непрерывно (постоянно), поэтому нет формальных фаз, которые могли бы служить отправной точкой для капитализации. Однако, это не означает, что проекты финансируют сами себя. Вместо этого компании в SAFe организуют долгосрочные потоки ценности в потоках поставки ценности (Value Streams). Команда Agile Release Train (ART), работающая с заданной Program Increment (PI) частотой, реализуют их.

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

Команда ART также помогает установить осуществимость различных портфельных инициатив (Эпики), которые управляются с помощью Kanban Портфеля. Это технико-экономическое обоснование в чем-то похоже на ранние этапы каскадной разработки и, как правило, оплачивается до тех пор, пока не будет дана рекомендация «начать», затем начнется разработка новых фич. Это означает, что оба типа работы обычно присутствуют в любом PI, в любом отчетном периоде.

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

Рисунок. 2. Многие типы работы выполняются в пределах заданного временного интервала PI

Категоризация фич для операционных и капитальных затрат

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

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

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

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

Инструмент гибкого управления жизненным циклом (Agile Lifecycle Management, ALM) может поддерживать определение, сбор и работу, связанную с реализацией историй. Путем связывания историй с фичами, когда это поддерживается инструментом (обычно посредством иерархии или обычного связывания), работа, связанная с разработкой фичами, может быть определена для потенциальной обработки капитальных затрат. Различные функции запросов в инструменте ALM могут помочь автоматизировать необходимые сводные вычисления.

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

Таблица 2. Возможные механизмы отслеживания усилий, связанных с историями CapEx

По часам историй

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

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

Примечание: во время планирования некоторые Agile-команды разбивают истории на задачи и оценивают часы выполнения задач. Этот метод требует регистрации фактического количества часов команды потраченного на истории; постановка задач не является обязательной.

По Story Points

Story Points — распространенная валюта в Scrum. Scrum-команды оценивают истории в условных единицах и обновляют свои оценки до фактических, чтобы улучшить будущие оценки. Хотя оценки являются относительными, а не абсолютными единицами измерения, это все, что необходимо.

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

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

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

По количеству историй

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

В рамках одного PI часто бывает, что ART реализует многие сотни историй различных типов и размеров (например, 10 команд, 10 историй на итерацию, более 4 итераций, дают 400 историй на PI).

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

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

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

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

Какую работу подлежит учитывать в капитальных расходах?

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

• Зарплаты членов Agile-команды, напрямую участвующих в разработке, внедрении и тестировании историй, могут быть подвержены капитальным затратам, что в значительной степени согласуются с существующей практикой waterfall. Это могут быть разработчики программного обеспечения и тестировщики, а также специалисты по управлению пользовательским опытом (User Experience, UX) и другие эксперты в данной области.
• Кроме того, владельцы продуктов (Product Owners, POs) и Scrum-мастера являются частью Agile-команды и вносят непосредственный вклад в формулирование и реализацию истории. Этот косвенный труд напрямую связан с созданием добавочной ценности и, таким образом, может подходить для учета капитальных затрат. Этого можно добиться, добавив больше усредненных затрат к истории с капитальными вложениями.
• Кроме того, не вся работа над функциями выполняется только членами Agile-команды. Системные архитекторы, Системные Команды и ИТ-специалисты также вносят свой вклад в разработку фич. Часть их затрат также может быть покрыта капитальными затратами.
• И наконец, дополнительные роли в процессе разработки решений могут способствовать созданию ценности через Pre- и Post-PI Planning, создания и поддержку Solution Intent или Демонстрацию Решения. Несмотря на то, что все эти типы активности и роли еще больше отдалены от конкретных задач по внедрению, они приносят пользу. Таким образом, их потенциал для учета капитальных затрат может быть уместным, по решению организации.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.