Dezember, Budget-Session. Der CTO präsentiert den Plan für 2026: „Wir brauchen 8 neue Entwickler, das sind 2,4M PLN”. Der CFO antwortet: „Du hast Headcount und Kosten gezeigt. Wo ist der Business Case? Wie ist der ROI? Was bekommen wir für diese 2,4M?”. Der CTO versucht zu improvisieren: „Schnellere Feature-Lieferung, weniger Bugs…”. Der CFO unterbricht: „Das sind keine Zahlen. Komm mit etwas Konkretem zurück.”
Diese Szene wiederholt sich in Technologieunternehmen mit frustrierender Regelmäßigkeit. IT spricht die Sprache der Technologie (Velocity, Tech Debt, Skalierbarkeit), Finance spricht die Sprache des Business (ROI, Payback-Periode, TCO). Ohne Übersetzung wird Budgetierung zum Kampf, nicht zur Zusammenarbeit. Der CTO fühlt, dass Finance „nicht versteht”, der CFO fühlt, dass IT „nicht begründen kann”. Die Wahrheit: beide Seiten haben recht, ein gemeinsames Framework fehlt.
Warum scheitert der Standardansatz zur IT-Budgetierung?
Historische Budgetierung - „gib mir das gleiche wie letztes Jahr plus Inflation” - funktioniert nicht für Entwicklungsteams. IT ist kein statisches Cost Center wie Büro oder Nebenkosten. Bedürfnisse ändern sich mit Produkt, Markt, Technologie. Das Budget vom Vorjahr zu kopieren ignoriert diese Änderungen.
Zero-Based Budgeting - „begründe jeden Euro von Grund auf” - ist theoretisch besser, führt aber oft zu Entscheidungslähmung und politischen Spielen. Jede Position wird hinterfragt, was defensive Positionierung statt strategisches Denken erzwingt.
Headcount-getriebene Budgetierung - „ich brauche X Personen” - übersieht die fundamentale Frage: wofür? Den CFO interessiert nicht, wie viele Köpfe Sie haben - ihn interessiert, was diese Köpfe produzieren und für wie viel. Headcount ist Input, nicht Output.
Technologie-zuerst-Budgetierung - „wir müssen den Stack modernisieren” - spricht zu Technologen, nicht zum Business. Der CFO weiß nicht (und muss nicht wissen), warum Kubernetes besser ist als das, was wir haben. Er muss wissen, welches Geschäftsproblem es löst und wie der Return ist.
Projektbasierte Budgetierung ohne Portfolio-Sicht - eine Liste von Projekten mit Kosten, ohne Verbindung zu den strategischen Prioritäten des Unternehmens. Finance sieht Fragmente, nicht das Gesamtbild. Keine Klarheit, wie das IT-Budget auf Geschäftsziele abbildet.
Wie baut man ein Total Cost of Ownership Modell für ein IT-Team?
TCO beginnt mit vollständiger Kostenidentifikation - nicht nur Gehalt. Jede Person im IT-Team generiert direkte und indirekte Kosten, die für ein akkurates Bild berücksichtigt werden müssen.
Direkte Kosten pro Person: Bruttogehalt, Arbeitgeberbeiträge (Sozialversicherung, Fonds - ungefähr 20% über Brutto), Benefits (Krankenversicherungspaket, Fitnessmitgliedschaft, Versicherung - typisch 500-1500 PLN/Monat), Schulungen und Konferenzen (Jahresbudget - 5000-15000 PLN), Ausstattung (Laptop, Monitore, Zubehör - jährlich amortisiert etwa 5000-8000 PLN).
Indirekte Kosten pro Person: Büro (Flächenkosten, Nebenkosten - 1000-2500 PLN/Monat in einer Großstadt), Software-Lizenzen (IDE, Tools, SaaS pro Seat - 500-2000 PLN/Monat), HR- und Verwaltungs-Overhead (Recruiting, Onboarding, Payroll - etwa 5-8% der Personalkosten).
Vollkostenformel: Bruttogehalt × 1,45-1,55 für vollgeladene Kosten. Ein Entwickler mit 25.000 PLN brutto kostet tatsächlich 36.000-39.000 PLN monatlich. Jährlich: 430.000-470.000 PLN. Das sind die Zahlen, die der CFO sehen muss - nicht das Headline-Gehalt.
Kontraktoren und Body Leasing im Kostenmodell. Der Rechnungssatz enthält bereits den meisten Overhead - aber bedenken Sie versteckte Kosten: Onboarding-Zeit, Wissenstransfer, Management-Overhead. Zum Vergleich mit Festanstellung: multiplizieren Sie den Satz mit 12 und vergleichen Sie mit den vollgeladenen Mitarbeiterkosten.
Build vs. Buy Analyse. Festanstellung: höhere Upfront-Kosten (Recruiting, Onboarding), niedrigere langfristige Stückkosten, Risiko fester Verpflichtung. Kontraktoren: niedrigere Upfront (sofort verfügbar), höhere Stückkosten, Flexibilität. Ein Hybridmodell ist oft optimal: Kernteam angestellt, variable Kapazität durch Kontraktoren.
Wie präsentiert man ROI aus IT-Team-Investitionen?
Revenue Attribution - direkter IT-Beitrag zum Umsatz. Ein neues Feature, das X neue Kunden generiert × durchschnittlicher Umsatz pro Kunde = zugeordneter Umsatz. Checkout-Conversion-Optimierung um 2 Prozentpunkte × aktueller Traffic = zusätzlicher Umsatz. Das sind Zahlen, die der CFO versteht und schätzt.
Kostenvermeidung - Kosten verhindern, die ohne die Investition entstünden. Modernisierung eines Systems, das ausfallen würde = vermiedene Ausfallkosten. Automatisierung eines manuellen Prozesses = eingesparte FTEs. Security-Verbesserungen = risikoadjustierte Kosten eines potenziell vermiedenen Breaches.
Produktivitätsmultiplikator - wie neue Leute den Output des gesamten Teams beeinflussen. Nicht nur „8 neue Devs = 8× mehr Code”. Ein Senior Developer, der Juniors mentort, erhöht deren Produktivität. Ein DevOps Engineer, der Pipelines automatisiert, erhöht die Velocity aller. Quantifizieren Sie den Multiplikatoreffekt.
Time-to-Market-Wert. Schnellere Feature-Lieferung = früherer Umsatz. Wenn ein neues Produkt 100.000 PLN monatlich generiert und zusätzliche Ressourcen den Launch um 3 Monate beschleunigen = 300.000 PLN zusätzlicher Umsatz. Das ist ein überzeugendes Argument.
Opportunitätskosten-Perspektive. „Was verlieren wir, wenn wir NICHT investieren?” Verzögerte Projekte = verlorener Marktanteil. Überlastetes Team = höhere Fluktuation = Recruiting- und Schulungskosten. Anhäufung technischer Schulden = zukünftige Velocity-Reduktion. Als Risiko framen, nicht nur als verpasste Chance.
Payback-Periode-Berechnung. Investition von 2,4M PLN ins Team, erwarteter zusätzlicher Wert von 4M PLN jährlich = Payback in 7-8 Monaten. Das ist eine Metrik, die der CFO versteht. Wenn Payback > 24 Monate - die Investition ist fragwürdig; < 12 Monate - überzeugend.
Wie baut man ein Capacity Planning Modell?
Demand Forecast - wie viel Arbeit erwarten wir? Produkt-Roadmap übersetzt in Aufwand. Jedes Epic geschätzt in Story Points oder Personentagen. Aggregation ergibt Gesamtbedarf. Über Quartale verteilen - Demand ist nicht flach.
Supply-Analyse - wie viel Kapazität haben wir? Anzahl Entwickler × verfügbare Arbeitstage × produktive Zeit (typisch 70-80% nach Abzug von Meetings, Urlaub, Krankheit). Aktuelle Kapazität = X Story Points pro Quartal.
Gap-Analyse - Demand minus Supply. Wenn Demand = 2000 Story Points/Q, Supply = 1500 - Gap = 500, bedeutet Sie brauchen +33% Kapazität. Übersetzt in Headcount: 500 ÷ durchschn. Velocity pro Dev = wie viele neue Leute.
Buffer-Planung - planen Sie nicht für 100% Auslastung. Unerwartete Arbeit (Bugs, dringende Anfragen, Produktionsprobleme) verbraucht 15-25% der Kapazität. Ramp-up-Zeit für neue Leute (3-6 Monate bis volle Produktivität). Fluktuations-Ersatz (durchschnittlich 15% gehen jährlich). Bauen Sie Buffer ein.
Szenario-Planung - optimistisch, realistisch, pessimistisch. Was wenn Demand schneller wächst? Was wenn langsamer? Was wenn eine Schlüsselperson geht? Ein Budget mit Varianten gibt dem CFO Zuversicht, dass Sie über Risiken nachdenken.
Quartalsweise Rekalibrierung - Capacity Plan ist keine einmalige Übung. Quartalsreview: Ist die Lieferung auf Kurs mit dem Plan? Hat sich Demand geändert? Passen Sie die Vorausschau an. Zeigen Sie dem CFO, dass Sie überwachen und anpassen.
Wie kategorisiert und priorisiert man IT-Ausgaben?
Run vs. Grow vs. Transform Framework. Run: bestehende Systeme aufrechterhalten, Support, Wartung - Must Have, aber generiert keinen neuen Wert. Grow: Produkte entwickeln, neue Features, kundenorientierte Verbesserungen - generiert Umsatz. Transform: Modernisierung, neue Plattformen, Tech Enablement - ermöglicht zukünftiges Wachstum.
Typische Verteilung: 60-70% Run, 20-30% Grow, 10-15% Transform. Wenn Run dominiert (80%+) - Organisation steckt fest, keine Innovation. Wenn Transform dominiert - wahrscheinlich Over-Engineering vor echtem Bedarf.
MoSCoW-Priorisierung für Projekte. Must Have: regulatorische Compliance, sicherheitskritisch, umsatzblockierende Fixes. Should Have: signifikanter Geschäftswert, angemessener ROI. Could Have: nette Verbesserungen, niedrigerer ROI. Won’t Have: aufschiebbar, geringer Wert.
Stack Rank aller Initiativen. Zwingen Sie sich, alles zu ordnen: wenn Sie nur 1 machen können, welche? Wenn 2? Wenn 5? Das eliminiert die „alles ist Priorität”-Falle. Der CFO schätzt Klarheit.
Investment vs. Expense Perspektive. CapEx (kapitalisiert: Produktentwicklung, neue Plattformen) vs. OpEx (operativ: Wartung, Support, SaaS). Buchhaltungsbehandlung unterscheidet sich - prüfen Sie mit Finance, wie für optimale Darstellung zu klassifizieren.
Wie präsentiert man das IT-Budget in Geschäftssprache?
Mapping auf Geschäftsziele. Nicht „wir stellen 3 Backend-Devs ein” - „wir unterstützen das Ziel, die Kundenbasis um 40% zu erhöhen, durch Entwicklung neuer Features”. Jede Budgetposition verlinkt auf ein Geschäftsziel.
Metriken, die für den CFO zählen: Payback-Periode, ROI, Kosten pro Transaktion, Kosten pro gewonnenem Kunden, Umsatz pro Mitarbeiter. Übersetzen Sie technische Details in diese Metriken.
Risikosprache. „Ohne diese Investition riskieren wir: Verzögerung von Produkt X um 6 Monate (= 2M verlorener Umsatz), Abgang von Schlüsselentwicklern (= 400k Recruiting-Kosten), Sicherheitsbruch (= potenzielle 5M Haftung)”. Risikoquantifizierung resoniert mit Finance.
Benchmarking. „Unsere IT-Investition als % vom Umsatz ist 12%, der Benchmark für unsere Branche ist 10-15%, also sind wir in der Norm”. Externe Daten legitimieren interne Anfragen.
Visuelles Storytelling. Charts > Tabellen > Text. Trendlinien, die Kapazitätslücke zeigen. Tortendiagramme, die Budgetallokation zeigen. Waterfall, das Kostenaufbau zeigt. Der CFO verarbeitet hunderte Seiten - machen Sie es scanbar.
Executive Summary zu Beginn. Eine Seite: was Sie verlangen, warum, welcher Return, welches Risiko ohne es. Details im Anhang für Interessierte.
Wie managt man das IT-Budget während des Jahres?
Monatliches Kostentracking vs. Budget. Varianzanalyse: warum haben wir mehr/weniger ausgegeben? Ein Ausreißer ist Rauschen, ein Trend ist Signal. Frühwarnung für Probleme.
Quartalsweise Reforecast. Das initiale Budget war eine Schätzung - besser als zufällig, aber eine Schätzung. Mit Daten aus Q1, aktualisieren Sie die Prognose für Q2-Q4. Der CFO schätzt proaktive Updates, keine Überraschungen zum Jahresende.
Contingency-Management. 10-15% des Budgets als Contingency für unerwartete Bedürfnisse. Governance, wer es nutzen kann und wofür. Ungenutzte Contingency ist kein Versagen - es ist diszipliniertes Management.
Einsparungen-Reinvestitions-Advocacy. Wenn Sie Einsparungen finden (z.B. durch Optimierung, Neuverhandlung, nicht nachbesetzte Fluktuation) - verhandeln Sie mit dem CFO, dass ein Teil zu IT für Prioritäten zurückfließt. Das incentiviert Effizienz.
Kostentransparenz für Teams. Jeder Team Lead sollte wissen, wie viel sein Team kostet. Baut Ownership und Bewusstsein. „Diese architektonische Entscheidung wird die Cloud-Kosten um 50k jährlich erhöhen” - informierte Abwägungen.
Wie berücksichtigt man versteckte Kosten und Risiken im Budget?
Technical Debt Servicing. Technische Schulden haben einen Zinssatz - Zeit für Workarounds, langsamere Entwicklung, mehr Bugs. Schätzen Sie: wie viel Kapazität verlieren Sie durch Schuldenservice? Das sind reale Kosten, unsichtbar im Standardbudget.
Fluktuationskosten. Durchschnittliche Kosten für Entwickler-Ersatz: 50-200% des Jahresgehalts (Recruiting, Onboarding, Ramp-up, verlorene Produktivität). Bei 15% Fluktuation und 30-Personen-Team gehen 4-5 Leute jährlich = versteckte Kosten von 500k-1M PLN.
Wissensverlust-Risiko. Wenn kritisches Wissen in den Köpfen von 2-3 Personen ist - was wenn sie gehen? Quantifizieren Sie: Kosten der Wissensrekonstruktion, Risiko für Projekte. Investition in Dokumentation und Wissensaustausch als Mitigation.
Burnout und Produktivitätsverfall. Ein überlastetes Team hat sinkende Produktivität. 60+ Stunden wöchentlich über längere Zeit = 20-30% Produktivitätsabfall. Mehr Leute einzustellen kann günstiger sein als das aktuelle Team zu „quetschen”.
Compliance- und Security-Kosten. Regulatorische Änderungen, Audit-Vorbereitung, Security-Incident-Response. Oft vergessen in der Baseline-Budgetierung, dann Überraschungsausgaben.
Wie verhandelt man das IT-Budget mit der Führung?
Hoch ankern, Verhandlung erwarten. Bitten Sie nicht um genau das, was Sie minimal brauchen - bitten Sie um etwas mehr. Verhandlungen werden erwartet; der Ausgangspunkt zählt.
Trade-offs explizit machen. „Ich kann A, B, C mit diesem Budget machen. Wenn das Budget kleiner ist, muss ich wählen: A und B ohne C, oder A und C mit verzögertem B”. Erzwingen Sie eine Entscheidung statt „gib mir weniger und ich werde es irgendwie schaffen”.
Zeigen Sie Ihre Hausaufgaben. Detaillierte Analyse baut Glaubwürdigkeit. „Ich habe jede Position überprüft, optimiert was ich konnte, hier ist was bleibt” ist stärker als runde Zahlen ohne Untermauerung.
CFO-Bedenken antizipieren. Wogegen werden sie Einwände erheben? Bereiten Sie Antworten vor. „Warum so viel für Schulungen?” - „Retention und Upskilling ist günstiger als externes Hiring”. „Warum neue Leute statt Überstunden?” - „Dauerhafte Überstunden führen zu Burnout und höherer Fluktuation, kosten langfristig mehr”.
An Unternehmensprioritäten ausrichten. Wenn der CEO über Expansion in einen neuen Markt spricht - Ihr Budget unterstützt das. Wenn Prioritäten Kostenreduktion sind - zeigen Sie, wie IT-Investitionen Kosten anderswo reduzieren.
Mehrjahresperspektive. Nicht nur 2026 - zeigen Sie die Trajektorie. „2026 investieren wir in Plattform, 2027 und 2028 ernten wir Vorteile in niedrigeren Run-Kosten und schnellerer Time to Market”.
Tabelle: IT-Team-Budget-Template für CFO
| Kategorie | 2025 Actual | 2026 Budget | Änderung | Begründung |
|---|---|---|---|---|
| PERSONAL | ||||
| Bestehender Headcount (30 FTE) | 13,2M PLN | 14,0M PLN | +6% | Inflationsanpassung, Merit Increases |
| Neueinstellungen (8 FTE) | - | 3,2M PLN | Neu | Unterstützung Wachstumsinitiative X (ROI: 18 Monate) |
| Kontraktoren/Body Leasing | 1,5M PLN | 1,8M PLN | +20% | Flex-Kapazität für Y-Projekt |
| Training & Entwicklung | 0,3M PLN | 0,4M PLN | +33% | Upskilling für neuen Stack, Retention |
| ZWISCHENSUMME PERSONAL | 15,0M PLN | 19,4M PLN | +29% | |
| TECHNOLOGIE | ||||
| Cloud-Infrastruktur | 2,4M PLN | 3,0M PLN | +25% | Skalierung für Nutzerwachstum 40% |
| Software-Lizenzen | 0,8M PLN | 0,9M PLN | +12% | Neue Tools, Seat-Erweiterung |
| Hardware-Erneuerung | 0,3M PLN | 0,4M PLN | +33% | 3-Jahres-Zyklus, Neueinstellungen |
| ZWISCHENSUMME TECH | 3,5M PLN | 4,3M PLN | +23% | |
| PROJEKTE | ||||
| Initiative X (Umsatz) | - | 1,2M PLN | Neu | Erwarteter Umsatz: 4M PLN/Jahr |
| Plattform-Modernisierung | 0,5M PLN | 0,8M PLN | +60% | Run-Kosten um 20% reduzieren in 2027 |
| Security & Compliance | 0,4M PLN | 0,5M PLN | +25% | Regulatorische Anforderung |
| ZWISCHENSUMME PROJEKTE | 0,9M PLN | 2,5M PLN | +178% | |
| CONTINGENCY (10%) | 1,9M PLN | 2,6M PLN | Puffer für Unbekanntes | |
| GESAMT IT-BUDGET | 21,3M PLN | 28,8M PLN | +35% |
Schlüsselmetriken:
- IT-Ausgaben als % vom Umsatz: 11% (Branchen-Benchmark: 10-14%)
- Payback auf neue Investitionen: 14 Monate
- Kosten pro Entwickler (vollgeladen): 467k PLN/Jahr
- Run/Grow/Transform-Aufteilung: 55% / 30% / 15%
IT-Budgetierung ist kein Kampf mit Finance - es ist eine kollaborative Übung in der Allokation begrenzter Ressourcen für maximalen Return. Ein CTO, der die Sprache des Business spricht, ROI zeigt und Trade-offs versteht, ist kein Bittsteller um Geld - er ist Partner in der Unternehmensstrategie.
Wichtige Erkenntnisse:
- TCO, nicht Headcount - zeigen Sie volle Kosten, nicht Headline-Zahlen
- ROI, nicht Technologie - übersetzen Sie in Geschäftswert und Metriken
- Capacity Planning basierend auf Demand - begründen Sie Bedarf mit Zahlen
- Run/Grow/Transform-Kategorisierung - zeigen Sie, wo das Geld hingeht
- Risikoquantifizierung - was wir durch Investition vermeiden
- Executive Summary + Details - bedienen Sie verschiedene Lesetiefen
Ein gut aufgebautes IT-Budget baut Vertrauen mit Finance und erleichtert zukünftige Gespräche. Ein schlecht aufgebautes schafft Zyklen von Konflikt und Misstrauen.
ARDURA Consulting unterstützt Organisationen bei der flexiblen IT-Team-Skalierung durch Body Leasing und Staff Augmentation, was Flexibilität in der Budgetplanung bietet. Sprechen wir darüber, wie wir bei der optimalen IT-Ressourcen-Budgetierung helfen können.