Управленческий учёт для IT-агентства: три цифры, говорящие всё

"₴12 млн годовой выручки. 15 разработчиков. Три года прибыли. И я, честно, не смогла бы ответить, если бы меня спросили, какой проект прибыльный, а какой медленно съедает деньги."

Основательница агентства IT-услуг описала момент прозрения на выездной встрече руководства. Её бизнес рос три года. Выручка с ₴4 млн до ₴12 млн. Штат с 5 до 15 разработчиков. Прибыль видна в конце года. По любому внешнему показателю — успешный.

Затем операционный директор задал вопрос: "Из наших 11 активных проектов какие два самые прибыльные в пересчёте на час работы разработчика?"

Она не смогла ответить. Бухгалтерские книги показывали выручку по проекту (иногда — когда проекты выставлялись к оплате чисто). Они не показывали часов разработчиков, распределённых по проектам. Они не показывали эффективной почасовой ставки после вычета простоев, выходных, внутренней работы. Они не показывали маржинального дохода по типу проекта (T&M против fixed-fee против retainer).

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

Эта статья — о трёх числах, которые нужны владелице IT-агентства, чтобы разобраться в своём бизнесе, и о том, почему стандартная бухгалтерия их не даёт, каким бы добросовестным ни был бухгалтер.

Парадокс: ₴12 млн выручки не означают ₴12 млн решений

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

Эти два числа слишком совокупны, чтобы управлять решениями. IT-агентство с выручкой ₴12 млн и чистой маржой 18% (₴2,16 млн прибыли) выглядит здоровым. Но:

• Если 60% выручки приходится на двух клиентов, в бизнесе есть скрытый риск концентрации
• Если самый прибыльный проект даёт маржу 38%, а наименее прибыльный — −4%, совокупное число скрывает и возможность (больше прибыльного типа), и проблему (убыточный проект)
• Если утилизация разработчиков держится на уровне 58%, а список проектов выглядит "полностью укомплектованным", это ₴1,4 млн нереализованной биллабельной мощности ежегодно
• Если команду отрывают от оплачиваемой клиентской работы на неоплачиваемую внутреннюю 20% времени, эффективная почасовая ставка драматически ниже объявленной

Совокупные числа говорят "ты прибыльный". Решениям нужно знать "где, с кем, на чём и насколько устойчиво". Управленческий учёт для IT-агентства построен именно так, чтобы ответить на это.

Общая рамка — управленческий учёт как дисциплина — в якорной статье → Управленческий учёт простыми словами.

Три числа, которые выдаёт управленческий учёт IT-агентства

Для агентства IT-услуг три числа выполняют бо́льшую часть работы по принятию решений. Число первое — утилизация на разработчика. Из часов, которые разработчик доступен для работы в месяц (~160), сколько были биллабельными для клиента? Типичный сервисный бизнес предполагает 100%. Честное число для IT-агентства — 60–75%, остальное — это поддержка продаж, внутренние инструменты, обучение, больничные, время на "скамейке" между проектами. Утилизация, отслеживаемая по каждому разработчику помесячно, показывает: кто надёжно загружен, кто между проектами, где прячется мощность, где агентство тихо переукомплектовано для текущего спроса.

Число второе — эффективная почасовая ставка на проект. Объявленные ставки амбициозны ("ставка нашего senior-разработчика — ₴1 800/час"). Эффективные ставки — это то, что фактически происходит после расползания скоупа, скидок ради загрузки разработчиков, невыставленных внутренних часов и переделок. Для здорового IT-агентства эффективная ставка составляет 75–90% от объявленной. Ниже 70% означает недооценку или утечку скоупа. Вычисленная по проекту, эта цифра говорит, какие проекты надёжно прибыльны, а какие тихо дрейфуют.

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

Эти три числа не появляются в P&L в налоговом формате. Они возникают, когда на чистую бухгалтерию накладывают управленческий учёт плюс тайм-трекинг. Статья №2 → раскрывает разницу между бухгалтерией и управленческим учётом; статья №4 → раскрывает операционный P&L, с которым это связано.

Как эти числа меняют ценообразование, найм и микс клиентов

Когда три числа существуют, четыре типа решений становятся структурированными, а не интуитивными.

Ценообразование. Вместо "оставим те же ставки, ведь клиенты не возражали" ценообразование становится таким: "наша эффективная ставка на этом клиенте — 67% от объявленной, мы теряем 33 пункта на утечке скоупа. Либо сужаем скоуп, либо поднимаем ставку на 30%". Конкретно. Обоснованно.

Найм. Вместо "мы чувствуем, что загружены, наймём ещё разработчика" найм становится таким: "утилизация по команде три месяца держится на 76% и, по прогнозу пайплайна, там и останется. Один дополнительный senior сразу поглотит 65% утилизации и достигнет 75% к третьему месяцу. В базовом сценарии — по карману, в пессимистичном — впритык". Смоделировано. Обосновано. Статья №5 → раскрывает финансовую модель, которая делает эти сценарии просчитываемыми.

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

Решения по линиям услуг. Когда маржинальный доход измеряется по типу проекта (fixed-fee разработка против T&M против постоянного retainer), агентство узнаёт, какие модели самые прибыльные, и соответственно смещает микс продаж. Многие агентства обнаруживают, что их наименее маржинальная работа — это та, которую они исторически больше всего любили, и действуют на основе этого.

Специфические для IT осложнения

Несколько реалий IT-агентства делают управленческий учёт сложнее, чем для других сервисных бизнесов, и ценнее, когда он сделан. Дисциплина тайм-трекинга. Без учёта часов по каждому разработчику и проекту утилизацию и эффективную ставку измерить невозможно. Большинство агентств начинают с инструмента (Toggl, Harvest, Clockify), и дисциплина формируется в течение 60–90 дней. Сама дисциплина выявляет проблемы: разработчик, который логирует 14 часов/день, намекает, что скоуп оценён ошибочно; разработчик, который логирует 4 часа/день на "внутреннее", выявляет недозагрузку.

Время на "скамейке". Между проектами разработчики стоят агентству, не принося биллинга. Это не мёртвый капитал — это подготовка, обучение, поддержка продаж. Но его нужно отслеживать и бюджетировать. Здоровое агентство держит ~10–15% времени на "скамейке". Свыше 25% — это проблема пайплайна продаж, а не выполнения.

Валютный риск. Многие украинские IT-агентства выставляют счета в USD или EUR, а платят в UAH. Колебания курса влияют на маржу. Управленческий учёт, который конвертирует всё в одну отчётную валюту по правильным курсам, показывает реальную маржу и выявляет, когда сдвиг маржи объясняется именно валютой, а не операционным изменением.

Микс типов проектов. Fixed-fee, T&M (time and materials), retainer, выделенная команда — каждый имеет разную динамику маржи, разный риск, разные сроки денежного потока. Агрегирование выручки по всем типам скрывает, какие модели наращивают долю, а какие теряют маржу.

Как внедрить управленческий учёт за 90 дней

Владелица агентства из вступления сделала это за квартал. Три фазы.

Фаза 1 — Фундамент (недели 1–4). Внедрите тайм-трекинг. Распределите все часы разработчиков на: биллабельные для конкретного клиента/проекта, внутренние (поддержка продаж, обучение, инструменты), "скамейка" (между проектами), административные. Добейтесь, чтобы каждый разработчик логировал часы последовательно. Первый месяц данных будет неполным — это ожидаемо.

Фаза 2 — Картирование (недели 5–8). Опишите каждый активный проект: выручка, ожидаемая дата завершения, полностью нагруженная себестоимость разработчика (зарплата + бенефиты + распределение оверхеда), прямые затраты (субподрядчики, инструменты). Посчитайте маржинальный доход по проекту за предыдущий квартал. Числа удивят. Статья №4 → раскрывает операционный P&L, с которым это связано.

Фаза 3 — Интеграция решений (недели 9–12). Имея трёхмесячные данные по утилизации и маржинальный доход по проекту, владелица принимает три решения: (1) один клиент на переоценку, (2) один клиент на отказ, (3) одно решение о найме, смоделированное против трёх сценариев. После этих решений практика установлена. В дело вступает ежемесячный ритм.

Статья №12 → раскрывает рамку ритма.

📌 Посмотрите, как управленческий учёт выглядит для агентства IT-услуг — утилизация, эффективная ставка, маржинальный доход по проекту — в одном интегрированном виде. Забронируйте 20-минутное демо Finmap. Мы пройдёмся по реальному примеру настройки агентства и покажем, как эти три числа выводят решения на поверхность. Забронировать демо Finmap →

Основа темы: Управленческий учёт: что это и зачем владельцу

Отрасль: Как Finmap помогает IT-компаниям навести финансовый порядок