Бюджет проекта: составление и контроль расходов

Проект укладывается в смету на бумаге и вылезает за нее в реальности – на 20%, 40%, иногда в два раза. Причина обычно не в воровстве и не в форс-мажоре, а в том, что бюджет считали один раз в начале и больше к нему не возвращались. Пока команда работает, цены на материалы меняются, подрядчик присылает допсоглашение, а резерв на риски давно потрачен на то, что риском не было.

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

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

Что такое бюджет проекта и зачем его составлять

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

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

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

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

Бюджет, смета, финансовый план и бюджет компании: где границы

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

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

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

На практике термины в разных компаниях смешивают: где-то смету называют бюджетом, а бюджет – финпланом. Мы в таких случаях смотрим не на название документа, а на его содержание. Если в нем есть сроки, источники денег и ответственные – это рабочий инструмент управления, а не просто расчет стоимости. Но если этих элементов нет, «бюджет» превращается в смету, как бы его ни называли.

Из чего складывается бюджет проекта

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

Доходы и источники финансирования – выручка от заказчика, собственные средства компании, грант, кредит. Для внутреннего проекта это может быть просто лимит, выделенный руководством.
Прямые расходы – то, что тратится непосредственно на результат: зарплата команды, оплата подрядчиков, закупка материалов или лицензий на софт.
Косвенные расходы – аренда офиса на проектную команду, связь, административная поддержка, часть зарплаты руководителя проекта, если он занят не только этой задачей.
Налоги и комиссии – банковские переводы, эквайринг, налоговые отчисления с зарплат, если проект их учитывает отдельно от бюджета компании.
Резерв на риски – обычно 5–15% от суммы прямых расходов, размер зависит от новизны проекта и количества непроверенных подрядчиков.
Денежный поток и финансовый результат – платежный календарь по датам и итоговая прибыль или убыток.

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

Как рассчитать бюджет проекта: последовательность действий

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

Дальше расчет идет по повторяемой цепочке шагов. Сначала – декомпозиция результата на этапы и задачи (WBS, work breakdown structure – иерархическая структура работ). Затем под каждую задачу подбираются ресурсы: люди, подрядчики, материалы, лицензии. После этого к ресурсам применяются ставки и цены. Это может быть часовая оплата специалиста, стоимость закупки или тариф подрядчика. Полученные суммы группируются по статьям бюджета, к ним добавляются налоги и косвенные расходы, а затем – резерв на риски. Отдельным шагом считаются доходы и точки, где может возникнуть кассовый разрыв – момент, когда расходы уже наступили, а деньги от заказчика еще не пришли. И в конце все сводят в единый документ и согласуют его с заказчиком или руководством.

На этом этапе важно не путать бюджет начислений с календарем платежей. Бюджет начислений показывает, когда работа выполнена и расход экономически возник – например, зарплата команды за месяц. Календарь платежей показывает, когда деньги физически списались или поступили. Зарплата может быть начислена в конце месяца, а выплачена только 10-го числа следующего. Если планировать проект только по начислениям, легко упустить момент, когда на счету физически не хватает денег для оплаты уже подтвержденного расхода.

Правильная последовательность разработки бюджета проекта выглядит так:

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

WBS как основа для цифр: без декомпозиции нет точного бюджета

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

По каждой задаче внутри этапа фиксируют пять вещей: объем работы в измеримых единицах, срок выполнения, исполнителя или роль, единицу измерения (часы, страницы, экраны интерфейса) и критерий готовности – что именно считается завершением задачи. Мы часто сверяемся с этим списком, когда проверяем смету перед согласованием. Строка бюджета «разработка – 500 000 ₽» без такой детализации не дает понять, за что именно платят деньги и можно ли контролировать прогресс по ней.

Если задача крупная и охватывает несколько недель работы разных специалистов, ее стоит дробить дальше. «Разработка» распадается на верстку, бэкенд, интеграции и настройку окружения – у каждой из этих подзадач свой исполнитель, свой срок и своя стоимость. Чем детальнее декомпозиция, тем точнее итоговая цифра бюджета и тем проще будет свести план-факт на этапе контроля расходов.

Источники денег и условия финансирования

Расходы планируют не отдельно от источника денег, а вместе с ним, потому что от источника зависит, когда деньги реально доступны. Если заказчик платит по графику «30% аванс – 40% на середине проекта – 30% по факту сдачи», это напрямую определяет, на какие статьи хватит денег в первый месяц работы, а какие придется финансировать из собственных средств компании или кредитной линии.

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

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

Методы оценки бюджета: когда какой применять

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

Метод	Когда применяют	Ограничение
Сверху вниз (top-down)	Есть заданный лимит бюджета, нужна предварительная оценка до детализации задач	Без последующей проверки снизу вверх легко занизить бюджет и не уложиться в сроки
Снизу вверх (bottom-up)	Есть детальная WBS, нужен прозрачный и точный расчет	Требует времени на декомпозицию всех задач
По аналогии	Проект похож на уже реализованные ранее	Точность зависит от того, насколько корректно выбран аналог
Параметрический	Стоимость линейно зависит от объема – цена за квадратный метр, за час, за единицу продукции	Не годится для уникальных задач без устойчивой зависимости цена/объем

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

Пример расчета: бюджет запуска лендинга с резервом и графиком платежей

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

Статья	Ед.	Кол-во	Ставка	Сумма	Этап	Срок платежа	Ответственный	Комментарий
Дизайнер (штат)	час	60	1 500 ₽	90 000 ₽	Дизайн	конец месяца	Руководитель проекта	оклад, не почасовая оплата
Разработчик (штат)	час	100	2 000 ₽	200 000 ₽	Разработка	конец месяца	Руководитель проекта	–
Копирайтер (подрядчик)	проект	1	25 000 ₽	25 000 ₽	Аналитика	по акту	Менеджер проекта	постоплата
Хостинг и домен	год	1	8 000 ₽	8 000 ₽	Запуск	предоплата	Разработчик	–
Реклама на запуск	месяц	1	60 000 ₽	60 000 ₽	Продвижение	предоплата	Маркетолог	тестовый бюджет
Комиссии и налоги	–	–	–	18 000 ₽	сквозная	по факту оплат	Бухгалтер	эквайринг + отчисления
Косвенные расходы	–	–	–	15 000 ₽	сквозная	ежемесячно	Руководитель проекта	связь, часть аренды
Резерв на риски	–	–	–	40 000 ₽	сквозная	по необходимости	Руководитель проекта	10% от прямых расходов

Итог считается суммированием всех строк – в примере получается 456 000 ₽ расходов. Если доход от заказчика зафиксирован отдельной строкой, например 550 000 ₽, плановый финансовый результат – это разница между доходом и суммой расходов. В примере выходит 94 000 ₽ прибыли. И чтобы увидеть потребность в оборотных деньгах, нужно разложить те же суммы по датам реального поступления и списания. Если аванс от заказчика приходит через две недели после старта, а зарплату команде и оплату рекламы нужно провести раньше, возникает разрыв, который придется закрывать из собственных средств компании.

Резерв на риски: под что закладывать и кто разрешает тратить

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

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

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

Как контролировать бюджет: план-факт и работа с отклонениями

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

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

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

Несколько типичных ошибок стоит держать в голове постоянно. Часто в план-факт забывают включить косвенные расходы и налоги, из-за чего плановая экономия оказывается мнимой. Начисления смешивают с платежами, и тогда картина денежного потока искажается. Обязательства по подписанным, но еще не оплаченным договорам не учитывают, и лимит бюджета кажется свободнее, чем он есть на самом деле. И отдельная ошибка – когда роль руководителя проекта по анализу отклонений подменяется чисто бухгалтерской сверкой цифр. Бухгалтерия фиксирует факт платежа, но не объясняет, почему он отличается от плана и что с этим делать.

Минимальный набор метрик для еженедельной проверки

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

план расходов на период и факт – сколько было запланировано и сколько реально потрачено;
отклонение в рублях и в процентах одновременно;
обязательства – суммы по подписанным договорам, которые еще не оплачены, но уже зафиксированы;
остаток лимита бюджета по проекту;
прогноз итоговой суммы до завершения проекта (EAC, estimate at completion – оценка полной стоимости с учетом текущих тенденций);
использование резерва – сколько уже списано и на какие риски;
плановые поступления от заказчика или другого источника финансирования;
остаток денег на счете и, если проект работает с заказчиком, просрочка по оплате его счетов.

Процент отклонения без абсолютной суммы может вводить в заблуждение. Отклонение 20% на статье в 10 000 ₽ не требует внимания, а отклонение 3% на статье в 5 000 000 ₽ – уже серьезная сумма. Смотреть нужно на оба показателя вместе. Но и здесь важно не превращать контроль в формальность: цель – вовремя понять, что происходит, а не просто заполнить отчет.

Когда корректировать бюджет и кто это утверждает

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

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

В проектах с внешним заказчиком любое изменение, которое влияет на бюджет, сроки или объем, оформляется как формальный запрос на изменение (change request) с описанием причины, влияния на бюджет и подписью стороны, которая изменение одобряет. Устные договоренности об «небольшой доработке за те же деньги» – частая причина, по которой план-факт расходится, а виновного потом установить невозможно. И лучше проговорить этот момент в начале, чем разбираться с ним в конце проекта.

Универсальный шаблон бюджета и проверка перед утверждением

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

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

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

Чек-лист перед утверждением бюджета

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

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

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