Contabilità gestionale per un'agenzia IT: i tre numeri che ti dicono tutto
"₴12M di ricavi annuali. 15 sviluppatori. Tre anni in utile. E onestamente non avrei saputo dire, se me lo avessero chiesto, quale progetto fosse redditizio e quale una lenta perdita."
La fondatrice di un'agenzia di servizi IT ha raccontato il momento della presa di coscienza durante un offsite del management. La sua azienda era cresciuta per tre anni. Ricavi da ₴4M a ₴12M. Team da 5 a 15 sviluppatori. Utile visibile a fine anno. Secondo ogni parametro esterno — un successo.
Poi il COO ha posto una domanda: "Dei nostri 11 progetti attivi, quali due sono i più redditizi per ora di sviluppatore?"
Non ha saputo rispondere. I libri contabili mostravano i ricavi per progetto (a volte — quando i progetti venivano fatturati in modo pulito). Non mostravano le ore degli sviluppatori allocate per progetto. Non mostravano la tariffa oraria effettiva dopo aver sottratto tempi morti, ferie, lavoro interno. Non mostravano il margine di contribuzione per tipo di progetto (T&M vs fixed-fee vs retainer).
Sapeva che il suo margine aggregato era sano. Non sapeva quali clienti lo generassero e quali stessero silenziosamente sovvenzionando la crescita dell'agenzia a scapito del proprio margine.
Questo articolo parla dei tre numeri di cui una titolare di agenzia IT ha bisogno per capire il proprio business — e del perché la contabilità standard non li produce, per quanto diligente sia il commercialista.
Il paradosso: ₴12M di ricavi non significano ₴12M di decisioni
La maggior parte dei titolari di agenzie presta attenzione a due numeri: ricavi e utile netto. Sono i numeri che produce il commercialista, i numeri che si citano presentando l'azienda, i numeri che si osservano mese dopo mese.
Questi due numeri sono troppo aggregati per guidare le decisioni. Un'agenzia IT con ₴12M di ricavi e un margine netto del 18% (₴2.16M di utile) sembra sana. Ma:
- Se il 60% dei ricavi proviene da due clienti, l'azienda ha un rischio di concentrazione nascosto
- Se il progetto più redditizio genera un margine del 38% e il meno redditizio un −4%, l'aggregato nasconde sia un'opportunità (fare di più del tipo redditizio) sia un problema (chi genera perdite)
- Se l'utilizzo degli sviluppatori è al 58% ma l'elenco progetti sembra "pienamente coperto", ci sono ₴1.4M di capacità fatturabile non sfruttata ogni anno
- Se il team viene distolto dal lavoro pagato dai clienti verso lavoro interno non fatturato il 20% del tempo, la tariffa oraria effettiva è drasticamente inferiore a quella pubblicata
I numeri aggregati dicono "sei redditizio". Le decisioni hanno bisogno di sapere "dove, con chi, su cosa e quanto stabilmente". La contabilità gestionale per un'agenzia IT è strutturata proprio per rispondere a questo.
Il quadro generale — la contabilità gestionale come disciplina — si trova nell'articolo pilastro → La contabilità gestionale spiegata.
I tre numeri che la contabilità gestionale produce per un'agenzia IT
Per un'agenzia di servizi IT, tre numeri fanno gran parte del lavoro che guida le decisioni.
Numero uno — Tasso di utilizzo per sviluppatore. Delle ore in cui uno sviluppatore è disponibile a lavorare in un mese (~160), quante sono state fatturabili a un cliente? La tipica azienda di servizi presume il 100%. Il numero onesto per un'agenzia IT è 60–75% — il resto è supporto vendite, strumenti interni, formazione, malattia, bench time tra un progetto e l'altro. L'utilizzo monitorato per sviluppatore ogni mese rivela: chi è caricato in modo affidabile, chi è tra un progetto e l'altro, dove si nasconde la capacità, dove l'agenzia è silenziosamente sovradimensionata rispetto alla domanda attuale.
Numero due — Tariffa oraria effettiva per progetto. Le tariffe pubblicate sono aspirazionali ("la nostra tariffa senior dev è ₴1.800/ora"). Le tariffe effettive sono ciò che accade realmente dopo lo scope creep, gli sconti bench per tenere occupati gli sviluppatori, le ore interne non fatturate e il rework dei progetti. Per un'agenzia IT sana, la tariffa effettiva è il 75–90% di quella pubblicata. Sotto il 70% significa sottoprezzo o scope leakage. Calcolato per progetto, questo numero dice quali progetti sono affidabilmente redditizi e quali stanno silenziosamente peggiorando.
Numero tre — Margine di contribuzione per progetto (e per tipo di progetto). Ricavi meno costi diretti di delivery (tempo sviluppatore a costo pienamente caricato, subappaltatori, strumenti assegnati al progetto) prima dell'overhead allocato. Calcolato per progetto, è il segnale strategico più importante: dice quale lavoro vale la pena perseguire di più, quale riprezzare, quali clienti approfondire, quali licenziare.
Questi tre numeri non compaiono in un P&L formattato ai fini fiscali. Emergono sovrapponendo la contabilità gestionale a una contabilità pulita più il monitoraggio del tempo. L'articolo #2 → copre la distinzione contabilità vs contabilità gestionale; l'articolo #4 → copre il P&L operativo a cui questo si collega.
Come questi numeri cambiano il pricing, le assunzioni e il mix clienti
Quando i tre numeri esistono, quattro tipi di decisioni diventano strutturate invece che istintive.
Pricing. Invece di "teniamo le stesse tariffe perché i clienti non hanno protestato", il pricing diventa: "la nostra tariffa effettiva su questo cliente è il 67% di quella pubblicata — stiamo perdendo 33 punti per scope leakage. O restringiamo lo scope o alziamo la tariffa del 30%". Specifico. Difendibile.
Assunzioni. Invece di "ci sentiamo impegnati, assumiamo un altro sviluppatore", l'assunzione diventa: "l'utilizzo del team è al 76% da tre mesi, proiettato a restare lì dato il pipeline. Un senior in più assorbirebbe subito il 65% di utilizzo e raggiungerebbe il 75% entro il terzo mese. Sostenibile nello scenario base, teso in quello peggiore". Modellato. Giustificabile. L'articolo #5 → copre il modello finanziario che rende eseguibili questi scenari.
Mix clienti. Invece di "tutti i clienti sono più o meno simili", il mix clienti diventa gestito: si abbandonano i due clienti con margine di contribuzione negativo, si approfondiscono i tre con margine superiore alla media, si propone un adeguamento tariffario ai due clienti intermedi la cui tariffa effettiva è silenziosamente sotto soglia.
Decisioni sulle linee di servizio. Quando il margine di contribuzione viene misurato per tipo di progetto (lavoro fixed-fee vs T&M vs retainer continuativo), l'agenzia scopre quali modelli sono più redditizi e sposta di conseguenza il mix di vendita. Molte agenzie scoprono che il lavoro a margine più basso è quello che storicamente hanno apprezzato di più — e agiscono di conseguenza.
Le complicazioni specifiche del settore IT
Alcune realtà tipiche delle agenzie IT rendono la contabilità gestionale più difficile rispetto ad altre aziende di servizi — e più preziosa quando viene fatta bene.
Disciplina di monitoraggio del tempo. Senza un tracciamento delle ore per sviluppatore e per progetto, utilizzo e tariffa effettiva non si possono misurare. La maggior parte delle agenzie inizia con uno strumento (Toggl, Harvest, Clockify) e la disciplina emerge nell'arco di 60–90 giorni. La disciplina stessa rivela i problemi: uno sviluppatore che registra 14 ore/giorno suggerisce uno scope mal valutato; uno sviluppatore che registra 4 ore/giorno come "interno" rivela un sottoutilizzo.
Bench time. Tra un progetto e l'altro, gli sviluppatori costano all'agenzia senza generare fatturazione. Non è capitale morto — è preparazione, formazione, supporto vendite. Ma va monitorato e messo a budget. Un'agenzia sana ha circa il 10–15% di bench time. Sopra il 25% è un problema di pipeline vendite, non di delivery.
Esposizione valutaria. Molte agenzie IT ucraine fatturano in USD o EUR pagando in UAH. Le oscillazioni del cambio influenzano il margine. Una contabilità gestionale che converte tutto in un'unica valuta di reporting ai tassi corretti fa emergere il margine reale — e rivela quando il cambio, e non un cambiamento operativo, spiega una variazione di margine.
Mix dei tipi di progetto. Fixed-fee, T&M (time and materials), retainer, dedicated team — ciascuno ha dinamiche di margine diverse, rischio diverso, tempistiche di cash flow diverse. Aggregare i ricavi tra tutti i tipi nasconde quali modelli stanno guadagnando quota e quali stanno erodendo margine.
Come implementare la contabilità gestionale in 90 giorni
La titolare dell'agenzia dell'apertura ha fatto questo nell'arco di un trimestre. Tre fasi.
Fase 1 — Fondamenta (settimane 1–4). Installa il monitoraggio del tempo. Categorizza tutte le ore degli sviluppatori in: fatturabili a cliente/progetto specifico, interne (supporto vendite, formazione, strumenti), bench (tra un progetto e l'altro), amministrative. Fai in modo che ogni sviluppatore registri le ore in modo costante. Il primo mese di dati è incompleto — è normale.
Fase 2 — Mappatura (settimane 5–8). Mappa ogni progetto attivo: ricavi, data di fine prevista, costo pienamente caricato dello sviluppatore (stipendio + benefit + allocazione overhead), costi diretti (subappaltatori, strumenti). Calcola il margine di contribuzione per progetto per il trimestre precedente. I numeri sorprenderanno. L'articolo #4 → copre il P&L operativo a cui questo si collega.
Fase 3 — Integrazione decisionale (settimane 9–12). Con tre mesi di dati sull'utilizzo e sul margine di contribuzione per progetto, la titolare prende tre decisioni: (1) un cliente da riprezzare, (2) un cliente da abbandonare, (3) una decisione di assunzione modellata su tre scenari. Dopo queste decisioni, la pratica è consolidata. Subentra la cadenza mensile.
L'articolo #12 → copre il framework della cadenza.
📌 Scopri come appare la contabilità gestionale per un'agenzia di servizi IT — utilizzo, tariffa effettiva, margine di contribuzione per progetto — in un'unica vista integrata. Prenota una demo Finmap di 20 minuti. Analizzeremo insieme un esempio reale di configurazione agenzia e ti mostreremo come i tre numeri fanno emergere le decisioni. [Prenota una demo Finmap →]
Domande frequenti
Utile ma non indispensabile. Le basi — utilizzo, tariffa effettiva, margine di contribuzione per progetto — si possono costruire con dei fogli di calcolo se esiste già il monitoraggio del tempo. La maggior parte delle agenzie migra a una piattaforma dopo 6–9 mesi perché la manutenzione manuale diventa un lavoro part-time. L'articolo #3 → copre l'opzione piattaforma.
Più piccola è l'agenzia, più concentrato è il rischio legato a un singolo progetto negativo. Un'agenzia con 3 sviluppatori in cui un progetto genera un margine del −20% sta perdendo oltre il 30% della produttività di uno sviluppatore. La versione più semplice di queste tre metriche è essenziale, non opzionale, a questa scala.
Il commercialista continua a occuparsi di compliance, tasse, buste paga. La contabilità gestionale si aggiunge sopra — usando il monitoraggio del tempo e i dati contabili per produrre le tre metriche. L'articolo #2 — Contabilità vs contabilità gestionale →
Una sintesi, di solito sì. Gli sviluppatori rispondono bene alla chiarezza su come sta andando l'azienda. I numeri specifici sull'utilizzo andrebbero discussi in modo strutturato (nei 1:1, nelle retrospettive di team), non come una sorveglianza ambientale.
Converti tutto in un'unica valuta di reporting al tasso del periodo, poi monitora l'impatto valutario come voce separata. Questo isola il margine "operativo" dal margine "valutario" — e rivela quando l'uno maschera l'altro.
Il primo mese di dati rivela i segnali più evidenti — di solito 1–2 clienti o progetti che avevano bisogno di essere riprezzati. Entro il terzo mese, il quadro è pienamente visibile e le decisioni diventano strutturate. Entro il sesto mese, fa parte del modo in cui l'agenzia funziona.
