Управлінський облік для 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-компаніям навести фінансовий порядок