Vezetői számvitel egy IT-ügynökségnek: a három szám, amely mindent elmond

"₴12 millió éves bevétel. 15 fejlesztő. Három éve nyereséges. És őszintén nem tudtam volna megmondani, ha megkérdezik, melyik projekt volt nyereséges, és melyik szivárogtatta lassan a pénzt."

Egy IT-szolgáltató ügynökség alapítója így írta le a felismerés pillanatát egy vezetői csapatépítőn. A vállalkozása három éven át növekedett. A bevétel ₴4M-ról ₴12M-ra nőtt. A létszám 5-ről 15 fejlesztőre. Az év végén nyereség mutatkozott. Minden külső mérőszám szerint — sikeres.

Aztán az operatív igazgató feltett egy kérdést: "A 11 aktív projektünk közül melyik kettő a legnyereségesebb fejlesztői óránként?"

Nem tudott válaszolni. A könyvelés megmutatta a projektenkénti bevételt (néha — amikor a projekteket tisztán számlázták). Nem mutatta a projektekre allokált fejlesztői órákat. Nem mutatta a tényleges óradíjat a holtidő, ünnepnapok, belső munka levonása után. Nem mutatta a fedezeti hozzájárulást projekttípusonként (T&M vs fix díjas vs retainer).

Tudta, hogy az összesített árrése egészséges. Nem tudta, hogy mely ügyfelek termelték ezt, és melyek finanszírozták csendben az ügynökség növekedését a saját árréséből.

Ez a cikk arról a három számról szól, amelyre egy IT-ügynökség tulajdonosának szüksége van ahhoz, hogy átlássa a vállalkozását — és arról, hogy a hagyományos könyvelés miért nem termeli ki ezeket, bármilyen alapos is a könyvelő.

A paradoxon: ₴12M bevétel nem jelent ₴12M-nyi döntést

A legtöbb ügynökségtulajdonos két számra figyel: a bevételre és a nettó nyereségre. Ezek azok a számok, amelyeket a könyvelőjük készít, amelyeket a vállalkozás bemutatásakor idéznek, amelyeket hónapról hónapra követnek.

Ez a két szám túlságosan összesített ahhoz, hogy döntéseket vezéreljen. Egy IT-ügynökség ₴12M bevétellel és 18%-os nettó árréssel (₴2,16M nyereség) egészségesnek tűnik. De:

• Ha a bevétel 60%-a két ügyféltől származik, a vállalkozásban rejtett koncentrációs kockázat van
• Ha a legnyereségesebb projekt 38%-os árrést hoz, a legkevésbé nyereséges pedig −4%-ot, az összesített szám egyszerre rejti el a lehetőséget (több a nyereséges típusból) és a problémát (a veszteséges)
• Ha a fejlesztői kihasználtság 58%-on áll, de a projektlista "teljesen leterheltnek" tűnik, akkor évente ₴1,4M kihasználatlan számlázható kapacitás van
• Ha a csapatot az idő 20%-ában elvonják a fizetett ügyfélmunkáról nem fizetett belső munkára, a tényleges óradíj drámaian alacsonyabb a publikáltnál

Az összesített számok azt mondják: "nyereséges vagy." A döntésekhez azt kell tudni, "hol, kivel, min és mennyire tartósan." Az IT-ügynökségek vezetői számvitele kifejezetten erre a kérdésre épül.

Az általános keretrendszer — a vezetői számvitel mint diszciplína — a törzscikkben található → A vezetői számvitel elmagyarázva.

A három szám, amelyet az IT-ügynökségek vezetői számvitele termel

Egy IT-szolgáltató ügynökség esetében három szám végzi a döntéshozatal legnagyobb részét. Első szám — kihasználtsági ráta fejlesztőnként. A fejlesztő havi rendelkezésre álló óráiból (~160) mennyi volt számlázható egy ügyfélnek? A tipikus szolgáltató vállalkozás 100%-ot feltételez. Az őszinte szám egy IT-ügynökségnél 60–75% — a maradék értékesítési támogatás, belső eszközök, képzés, betegszabadság, projektek közötti kihasználatlan idő. A fejlesztőnkénti, havonta követett kihasználtság megmutatja: ki van megbízhatóan leterhelve, ki van projektek között, hol rejtőzik a kapacitás, hol van az ügynökség csendben túllétszámozva a jelenlegi kereslethez képest.

Második szám — tényleges óradíj projektenként. A publikált díjak elvárás jellegűek ("a szenior fejlesztőnk díja ₴1800/óra"). A tényleges díjak azok, amelyek a scope-kúszás, a fejlesztők leterheltségét fenntartó kedvezmények, a nem számlázott belső órák és a projekt-újramunkálás után ténylegesen történnek. Egy egészséges IT-ügynökségnél a tényleges díj a publikáltnak 75–90%-a. 70% alatt alulárazásról vagy scope-szivárgásról van szó. Projektenként kiszámítva ez a szám megmutatja, mely projektek megbízhatóan nyereségesek, és melyek csúsznak csendben.

Harmadik szám — fedezeti hozzájárulás projektenként (és projekttípusonként). Bevétel mínusz közvetlen teljesítési költségek (fejlesztői idő teljes terhelt költségen, alvállalkozók, a projekthez rendelt eszközök) az allokált rezsi előtt. Projektenként számítva ez a legfontosabb stratégiai jelzés: megmutatja, melyik munkából érdemes többet vállalni, melyiket kell újraárazni, mely ügyfeleket érdemes elmélyíteni, melyeket kell elengedni.

Ez a három szám nem jelenik meg egy adózási formátumú eredménykimutatáson. A vezetői számvitel rárétegzéséből származnak a tiszta könyvelésre és az időnyilvántartásra. A 2. cikk → a könyvelés és a vezetői számvitel közötti különbséget tárgyalja; a 4. cikk → az ehhez kapcsolódó működési eredménykimutatást tárgyalja.

Hogyan változtatják ezek a számok az árazást, a felvételt és az ügyfélmixet

Amikor a három szám létezik, négyféle döntés strukturálttá válik az ösztönös helyett.

Árazás. Ahelyett, hogy "tartsuk meg ugyanazokat a díjakat, mert az ügyfelek nem tiltakoztak", az árazás így alakul: "a tényleges díjunk ennél az ügyfélnél a publikáltnak 67%-a — 33 pontot veszítünk a scope-szivárgás miatt. Vagy szűkítsük a scope-ot, vagy emeljük a díjat 30%-kal." Konkrét. Alátámasztható.

Felvétel. Ahelyett, hogy "úgy érezzük, elfoglaltak vagyunk, vegyünk fel még egy fejlesztőt", a felvétel így alakul: "a csapat kihasználtsága három hónapja 76%-on áll, a pipeline alapján ez várhatóan így is marad. Egy plusz szenior azonnal 65%-ra csökkentené a kihasználtságot, majd a harmadik hónapra elérné a 75%-ot. Az alapesetben megfizethető, a lefelé mutató forgatókönyvben szoros." Modellezett. Indokolható. Az 5. cikk → az ehhez a forgatókönyvekhez futtatható pénzügyi modellt tárgyalja.

Ügyfélmix. Ahelyett, hogy "minden ügyfél nagyjából hasonló", az ügyfélmix kezelté válik: leejtjük a két negatív fedezeti hozzájárulást hozó ügyfelet, elmélyítjük a három átlag feletti árrést hozót, díjkorrekciót javaslunk a két középmezőnyi ügyfélnek, akiknek tényleges díja csendben a küszöb alatt van.

Szolgáltatási sor döntések. Amikor a fedezeti hozzájárulást projekttípusonként mérik (fix díjas fejlesztői munka vs T&M vs folyamatos retainer), az ügynökség megtudja, mely modellek a legnyereségesebbek, és ennek megfelelően módosítja az értékesítési mixet. Sok ügynökség rájön, hogy a legalacsonyabb árrésű munka az, amelyet történetileg a legjobban élveztek — és eszerint cselekszik.

Az IT-specifikus buktatók

Néhány IT-ügynökségi sajátosság nehezebbé teszi a vezetői számvitelt, mint más szolgáltató vállalkozásoknál — és értékesebbé is, ha sikerül megvalósítani. Időnyilvántartási fegyelem. Fejlesztőnkénti, projektenkénti óranyilvántartás nélkül a kihasználtság és a tényleges óradíj nem mérhető. A legtöbb ügynökség egy eszközzel kezdi (Toggl, Harvest, Clockify), és a fegyelem 60–90 nap alatt alakul ki. Maga a fegyelem is feltárja a problémákat: ha egy fejlesztő napi 14 órát jelent, az arra utal, hogy a scope rosszul lett megbecsülve; ha egy fejlesztő napi 4 órát jelent "belső" munkára, az alulterheltséget mutat.

Padidő (bench time). Projektek között a fejlesztők számlázás nélkül terhelik az ügynökséget. Ez nem holt tőke — felkészülés, képzés, értékesítési támogatás. De nyilván kell tartani és tervezni kell. Egy egészséges ügynökség ~10–15% padidővel működik. 25% felett ez már értékesítési pipeline probléma, nem teljesítési probléma.

Devizakitettség. Sok ukrán IT-ügynökség USD-ben vagy EUR-ban számláz, miközben UAH-ban fizet. Az árfolyammozgások befolyásolják az árrést. Az a vezetői számvitel, amely mindent egyetlen elszámolási devizára vált át a megfelelő árfolyamon, feltárja a valós árrést — és megmutatja, mikor az árfolyam magyarázza az árrésváltozást, nem pedig az operatív változás.

Projekttípus-mix. Fix díjas, T&M (idő és anyag), retainer, dedikált csapat — mindegyiknek más az árrésdinamikája, más a kockázata, más a cash flow időzítése. A bevétel összesítése az összes típuson elrejti, mely modellek nyerik el a nagyobb részesedést, és melyek zsugorítják az árrést.

Hogyan vezessünk be vezetői számvitelt 90 nap alatt

A bevezetőben szereplő ügynökségtulajdonos ezt egy negyedév alatt tette meg. Három szakasz.

1. szakasz — Alapozás (1–4. hét). Vezessünk be időnyilvántartást. Kategorizáljunk minden fejlesztői órát: adott ügyfélnek/projektnek számlázható, belső (értékesítési támogatás, képzés, eszközök), padidő (projektek között), adminisztratív. Minden fejlesztő következetesen jelentse az óráit. Az első hónap adatai hiányosak — ez elvárható.

2. szakasz — Feltérképezés (5–8. hét). Térképezzünk fel minden aktív projektet: bevétel, várható befejezési dátum, teljes terhelt fejlesztői költség (bér + juttatások + rezsi allokáció), közvetlen költségek (alvállalkozók, eszközök). Számítsuk ki a fedezeti hozzájárulást projektenként az előző negyedévre. A számok meglepőek lesznek. A 4. cikk → az ehhez kapcsolódó működési eredménykimutatást tárgyalja.

3. szakasz — Döntésbe integrálás (9–12. hét). Három hónapnyi kihasználtsági adattal és projektenkénti fedezeti hozzájárulással a tulajdonos három döntést hoz: (1) egy ügyfélnél újraárazás, (2) egy ügyfél elengedése, (3) egy felvételi döntés három forgatókönyv alapján modellezve. E döntések után a gyakorlat megszilárdul. Ezt havi rendszeresség váltja fel.

A 12. cikk → a rendszerességi keretrendszert tárgyalja.

📌 Nézze meg, hogyan néz ki a vezetői számvitel egy IT-szolgáltató ügynökségnél — kihasználtság, tényleges óradíj, fedezeti hozzájárulás projektenként — egyetlen integrált nézetben. Foglaljon egy 20 perces Finmap demót. Végigvezetjük egy valós példaügynökség beállításán, és megmutatjuk, hogyan hozza felszínre a három szám a döntéseket. [Finmap demó foglalása →]