Бюджет ИТ: CAPEX, OPEX и разговор с финансовым директором

← назад к разделу

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

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

CAPEX и OPEX: что куда относится в ИТспросят на собеседовании

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

Для оборудования граница задаётся ФСБУ 6/2020 «Основные средства»: актив с материальной формой, который используется больше 12 месяцев и приносит выгоды (п. 4). Там же (п. 5) компания может установить лимит стоимости, ниже которого такие активы списываются в расходы сразу. Поэтому ноутбук в одной компании это основное средство, а в другой просто расход: смотрите учётную политику своей компании, а не чужой.

Почему финансисту важна разница

Для руководителя ИТ сто миллионов это сто миллионов. Для финансового директора сто миллионов CAPEX и сто миллионов OPEX это два разных события.

• Прибыль квартала. OPEX уменьшает прибыль сразу. CAPEX уменьшает её постепенно: система за 120 млн, введённая в эксплуатацию со сроком полезного использования 5 лет, при линейной амортизации даёт 24 млн расходов в год, а не 120 в год создания.
• EBITDA. Амортизация в этот показатель не входит. Капитализированная разработка улучшает EBITDA по сравнению с той же суммой в OPEX, и если от EBITDA зависят премии правления или ковенанты по кредитам, это не формальность.
• Разные лимиты и разные согласующие. Инвестиционный бюджет часто утверждает отдельный комитет с защитой каждого проекта, операционный режут проще и быстрее. Перенос затрат из одной корзины в другую без согласования ломает обе.
• Деньги и расходы расходятся во времени. Сервер оплачен в марте целиком, а в расходы попадает годами. Финансистам нужен и бюджет движения денежных средств, и бюджет расходов, и вы должны уметь дать оба.

Отсюда первый вопрос финансового директора к любой вашей заявке: «это капитальное или операционное, и на каком основании?»

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

С отчётности за 2024 год коммерческие организации учитывают нематериальные активы по ФСБУ 14/2022 «Нематериальные активы» (приказ Минфина России от 30.05.2022 № 86н, зарегистрирован в Минюсте 28.06.2022 № 69031). Применять раньше было можно по решению организации, прежнее ПБУ 14/2007 утратило силу с 1 января 2024 года. Бюджетная сфера стандарт не применяет.

По пункту 4 объект признаётся нематериальным активом, если одновременно:

1. не имеет материально-вещественной формы;
2. предназначен для использования в обычной деятельности, для управленческих нужд или для сдачи в пользование за плату;
3. будет использоваться дольше 12 месяцев;
4. способен приносить экономические выгоды, на которые у компании есть право (например, исключительное право или лицензия), и компания может ограничить к ним доступ других;
5. может быть выделен из других активов.

Программы для ЭВМ и базы данных прямо названы среди видов нематериальных активов (п. 12). Компания может установить лимит стоимости, ниже которого такие объекты сразу идут в расходы (п. 7).

Как именно затраты на разработку превращаются в актив, описывает ФСБУ 26/2020 «Капитальные вложения» в редакции приказа № 87н от 30.05.2022. Его раздел о НИОКТР применяется, когда актив создаётся в результате научно-исследовательских, опытно-конструкторских и технологических работ; относится ли к ним разработка вашей системы, компания определяет сама, и это первое, что стоит выяснить у финансистов. Затраты делятся на стадию исследований («получение новых научных или технических знаний») и стадию разработок (применение знаний для проектирования нового или значительно улучшенного продукта), границу компания проводит сама (п. 17.4). Капитализируются только затраты стадии разработок (п. 17.5), и только если одновременно (п. 17.3):

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

Затраты стадии исследований, затраты разработки без выполненных условий и затраты, которые нельзя однозначно отнести к одной из стадий, идут в расходы периода, и задним числом их в капитальные вложения не восстанавливают (п. 17.6). Организации, которые вправе вести упрощённый учёт, могут вообще не капитализировать, а относить такие затраты на расходы сразу (п. 4 ФСБУ 26/2020).

Международный аналог: МСФО (IAS) 38 «Нематериальные активы», введённый в действие в России приказом Минфина № 217н, на который ссылается сам ФСБУ 14/2022. Логика та же: исследования в расходы, разработка в актив при выполнении критериев. Если ваша компания отчитывается и по МСФО, правила разделения стадий удобно согласовать с финансистами один раз для обоих учётов.

Что из этого следует для руководителя ИТ: капитализация держится на данных, которые производит ваша команда. Бухгалтерия не знает, какой разработчик в марте делал новую систему, а какой чинил старую. Значит, нужен учёт времени по проектам, договорённость, где заканчивается исследование, и документ о вводе системы в эксплуатацию.

Глубже: что ломается при капитализациирасширенное

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

Вечная разработка. Амортизация начинается с даты признания актива (п. 38 ФСБУ 14/2022). Пока система не введена, затраты копятся в капитальных вложениях и не давят на прибыль. Соблазн держать продукт «в разработке» годами понятен, но проект без даты ввода вызывает вопросы аудитора и прячет реальную стоимость.

Списание мёртвой системы. Если систему перестали использовать из-за морального устаревания и перспектив нет, объект списывают (п. 45 ФСБУ 14/2022). Остаток стоимости разом бьёт по прибыли. Решение закрыть систему за 200 млн, из которых 120 ещё не самортизированы, финансовый директор должен узнать от вас заранее, а не из отчётности.

Срок полезного использования. Его определяет компания, с учётом ожидаемого морального устаревания (п. 31). Для ПО честный срок короче, чем хочется: пять лет для внутренней системы, которую каждый год переписывают наполовину, звучит смело.

Облако или своё железоспросят на собеседовании

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

Сравнивают не цену сервера и не цену виртуальной машины, а TCO, полную стоимость владения за горизонт, обычно 3-5 лет.

Условный пример на 5 лет. Своё: 60 млн на оборудование, 8 млн в год за площадку, 3 администратора по 6 млн в год с налогами, итого 60 + 40 + 90 = 190 млн. Облако с той же нагрузкой: 45 млн в год, но администраторов нужно двое, итого 225 + 60 = 285 млн. При ровной нагрузке своё дешевле. Если нагрузка в пиках втрое выше среднего и пик длится две недели в году, своё железо придётся покупать под пик, и расчёт может перевернуться. Цифры условные, смысл в структуре: в TCO обязательно попадают люди и запас под пик, их чаще всего забывают.

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

Годовой бюджетный циклспросят на собеседовании

У большинства компаний цикл одинаковый, меняются только даты.

1. Сбор потребностей (обычно август-октябрь). Финансы присылают шаблон и целевые рамки: «рост не больше N процентов». Вы собираете заявки с команд.
2. План. Отдельно люди (штат, найм по месяцам, индексация), инфраструктура, лицензии и подписки, подрядчики, капитальные проекты. Для каждого капитального проекта короткое обоснование: что получит бизнес, сроки, когда ввод.
3. Защита. Разговор с финансовым директором, потом комитет. Здесь режут, и здесь нужно знать, что вы готовы отдать.
4. Исполнение и план-факт. Ежемесячно: план, факт, отклонение, причина, прогноз до конца года. Финансы ненавидят не перерасход, а перерасход, о котором узнали в ноябре.
5. Перераспределение. Раз в квартал пересматривают прогноз. Экономию в одной статье можно попросить перенести в другую, но переход между CAPEX и OPEX или между разными центрами затрат обычно требует отдельного согласования.

Шаблон строки план-факта, которую финансисты понимают без пояснений:

Ключевая колонка последняя: отклонение без действия читается как потеря управления.

Штат, подрядчики и аутстаффспросят на собеседовании

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

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

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

Как защищать бюджет перед финансовым директоромспросят на собеседовании

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

Говорите в его единицах. Не «нам нужен Kubernetes», а «переход снижает расходы на инфраструктуру с 54 до 40 млн в год со второго года, вложения 25 млн, окупаемость около двух лет». Как переводить инженерные проблемы в деньги, показано в статье Технический долг.

Разделите бюджет на три слоя.

• «Запустить» (run): поддержание того, что уже работает. Его режут последним, и вы должны показать, что именно отключится при сокращении.
• «Развивать»: инициативы под цели бизнеса, каждая с владельцем со стороны бизнеса.
• «Обязательное»: требования регуляторов, безопасность, окончание поддержки версий. Дата и последствия, если не сделать.

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

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

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

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

Типичные ошибки

• Бюджет только в рублях без классификации. Заявка без деления на CAPEX и OPEX возвращается на доработку, и вы теряете неделю в самый плотный месяц.
• Забытые постоянные платежи. Капитальный проект запускают, а поддержку вендора, лицензии и облако под него на следующие годы в OPEX не закладывают.
• Экономия, которая «сгорает». В конце года тратят остаток, чтобы на следующий год не урезали. Финансы это видят по декабрьскому всплеску и режут сильнее.
• Сюрприз в план-факте. Перерасход по облаку, о котором руководитель узнаёт из отчёта финансов, а не из собственных алертов по расходам.
• Капитализация без учёта времени. Красиво на бумаге, разваливается на первом аудите.
• Сравнение облака и железа по цене сервера, без людей, площадки и запаса под пик.

Глубже: как разговаривать о деньгах на собеседованиирасширенное

На позицию руководителя направления почти всегда спрашивают про бюджет, и слабый ответ звучит как «бюджетом занимается финансовый отдел». Сильный ответ содержит три вещи: размер и структуру («180 млн в год, из них 60 процентов люди, 25 инфраструктура, 15 капитальные проекты»), механику («ежемесячный план-факт, квартальный пересмотр прогноза, капитальные проекты через инвестиционный комитет») и случай, когда вы что-то сократили или перераспределили и чем за это заплатили.

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

Коротко

• CAPEX это вложения в актив дольше года, расход размазан амортизацией; OPEX это расход текущего периода. Для финансиста это разные лимиты, разные согласующие и разное влияние на прибыль и EBITDA.
• Собственная разработка может стать нематериальным активом по ФСБУ 14/2022 (с отчётности за 2024 год) при выполнении признаков п. 4; капитализируются только затраты стадии разработок при условиях п. 17.3 ФСБУ 26/2020. Аналог в МСФО это IAS 38.
• Капитализация держится на данных ИТ: учёт времени по проектам, граница исследований и разработки, дата ввода.
• Облако или железо решают по TCO за 3-5 лет с людьми, площадкой и запасом под пик, и с учётом того, какие лимиты у компании в этом году.
• Бюджетный цикл: сбор, план, защита, ежемесячный план-факт с прогнозом, квартальное перераспределение.
• Штат для ядра, подрядчики под ограниченный результат, аутстафф, когда упёрлись в лимит численности; сравнивать по полной стоимости.
• Бюджет защищают в единицах финансиста, слоями «запустить, развивать, обязательное» и сценариями сокращения.

Что почитать дальше

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