Make-or-Buy - Eigene IT-Abteilung oder externer Entwicklungspartner?

Sobald ein KMU regelmäßig Software braucht, taucht früher oder später die Frage auf: eigene Entwickler einstellen oder Projekte extern vergeben? Die Antwort hängt weniger von der Unternehmensgröße ab als viele annehmen - sondern davon, wie das Softwarebedürfnis tatsächlich aussieht, wie planbar es ist und wie kritisch Domänenwissen für den Erfolg ist. Dieser Artikel geht ausschließlich auf die Frage eigenes Entwicklerteam vs. externer Entwicklungspartner ein - nicht auf die separate Entscheidung, ob eine Standard-Software eingekauft oder selbst gebaut werden soll.

Eigene IT-Abteilung: Wann sie sich lohnt

Eine interne Entwicklungsmannschaft lohnt sich, wenn Software ein dauerhafter, zentraler Teil deines Geschäftsmodells ist - etwa bei einem eigenen Produkt, das kontinuierlich weiterentwickelt wird. Der Vorteil: tiefes Domänenwissen, das mit jedem Projekt wächst, volle Kontrolle über Priorisierung und kurze Feedbackschleifen, weil das Team dieselben internen Prozesse und Systeme wie der Rest des Unternehmens kennt.

Die Kehrseite: Festanstellungen sind teuer und schwer reversibel. Gute Entwickler zu finden, einzuarbeiten und zu halten, ist gerade für KMU ohne Tech-Marke ein eigenständiges, langwieriges Projekt - bevor überhaupt die erste Zeile Code für dein eigentliches Vorhaben geschrieben wird. Hinzu kommen laufende Kosten unabhängig von der Auslastung: Gehälter, Sozialabgaben, Weiterbildung und Führungsaufwand fallen auch in Monaten an, in denen wenig zu entwickeln ist.

Externe Vergabe: Wann sie die bessere Wahl ist

Für klar abgegrenzte Projekte - eine neue App, ein internes Tool, ein Kundenportal - ist externe Vergabe in den meisten Fällen die effizientere Lösung. Du zahlst nur für das, was tatsächlich gebraucht wird, ohne Fixkosten für Zeiten ohne Projekt.

Selbst wenn du eine interne Entwicklermannschaft hast, sind für Projekte, die ein sehr spezialisiertes Know-how erfordern, externe Spezialisten oft die bessere Wahl. Bei sicherheitsrelevanten Anwendungen sind zum Beispiel die möglichen Risiko-Kosten durch Implementierungsfehler sehr hoch. Nischen-Know-how oder Cutting-Edge-Technologien können interne Entwicklerteams oft nur schwer oder langsam aufbauen, weil sich die Investition in ein einzelnes, selten benötigtes Spezialgebiet für ein internes Team kaum rechnet.

Die Voraussetzung: Externe Vergabe funktioniert nur gut, wenn die Anforderungen vor Vergabe klar dokumentiert sind und ein verbindlicher Festpreis vereinbart wird. Ohne diese beiden Elemente entstehen genau die Kontrollverlust-Ängste, die viele KMU überhaupt erst zur eigenen IT-Abteilung treiben.

Die Kosten ehrlich gegenüberstellen

Ein häufiger Fehler beim Make-or-Buy-Vergleich: Es wird nur der Stundensatz eines externen Anbieters mit dem Bruttogehalt eines Entwicklers verglichen. Das ergibt ein verzerrtes Bild. Zu den echten Vollkosten einer internen Stelle gehören:

Bruttogehalt plus Arbeitgeberanteile zur Sozialversicherung
Rekrutierungskosten (Recruiting, Vermittlungsprovisionen, Zeit der Fachabteilung für Vorstellungsgespräche)
Einarbeitungszeit, in der die Produktivität noch gering ist
Ausstattung, Lizenzen, Weiterbildung
Fixkosten auch in Phasen mit geringer Auslastung
Fluktuationsrisiko: Verlässt die Person das Unternehmen, beginnt die Einarbeitung eines Nachfolgers erneut

Bei externer Vergabe zum Festpreis kennst du dagegen die Gesamtkosten des Projekts vorab - vorausgesetzt, das Anforderungsdokument war präzise genug, um Nachträge zu vermeiden.

Der Denkfehler hinter "wir brauchen eigene Entwickler"

Viele Unternehmen entscheiden sich für eine eigene IT-Abteilung, weil eine frühere externe Vergabe schlecht gelaufen ist - Budget gesprengt, Scope Creep, unklare Verantwortlichkeiten. Das eigentliche Problem war dabei selten die externe Vergabe an sich, sondern fehlende Anforderungsklarheit und ein Vertragsmodell (meist Time & Material), das diese Unklarheit nicht abgefedert hat.

Mit einem präzisen Lastenheft und einem Festpreisvertrag verschwinden die meisten Gründe, die für eine teure interne Lösung sprechen. Wer zusätzlich vertraglich absichert, dass Quellcode, Dokumentation und Infrastruktur-Zugänge bei Projektabschluss vollständig ans eigene Unternehmen übergehen, verliert auch nicht die Kontrolle, die man sich von einem eigenen Team erhofft hatte.

Hybridmodelle: Das eine schließt das andere nicht aus

In der Praxis ist die Entscheidung selten ein reines Entweder-Oder. Häufige, funktionierende Mischformen:

Kleiner interner Kern, große Projekte extern: Ein bis zwei interne Entwickler pflegen bestehende Systeme und übernehmen die fachliche Schnittstelle zu externen Partnern, größere Vorhaben werden zum Festpreis vergeben.
Extern starten, intern übernehmen: Ein neues Produkt wird extern zum Festpreis aufgebaut; sobald es zum dauerhaften Kerngeschäft wird, entsteht darauf aufbauend ein internes Team, das die vollständige, vertraglich gesicherte Codebasis übernimmt.
Intern mit externer Spitzenlast: Das Kerngeschäft läuft über ein festes internes Team, punktuelle Spezialprojekte oder Lastspitzen werden extern zugekauft.

Eine pragmatische Entscheidungshilfe

Software ist dein Kerngeschäft und wird dauerhaft weiterentwickelt? → Eigene IT-Abteilung sinnvoll, ergänzt durch externe Partner für Lastspitzen und Spezialwissen.
Du brauchst ein einzelnes, klar abgegrenztes Projekt? → Externe Vergabe zum Festpreis, mit präzisem Anforderungsdokument.
Das Projekt erfordert seltenes Spezialwissen (z. B. Sicherheit, spezielle Compliance-Anforderungen)? → Externe Spezialisten, selbst wenn ein internes Team existiert.
Du bist unsicher, weil eine frühere externe Vergabe schiefgelaufen ist? → Das Problem war wahrscheinlich das Vertragsmodell, nicht das Prinzip externer Vergabe.

Was bei der externen Vergabe nicht verloren gehen darf

Ein Vorbehalt gegen externe Vergabe, den viele KMU zu Recht haben: Wandert das gesamte Projektwissen mit dem Dienstleister ab, sobald das Projekt endet? Das lässt sich vertraglich lösen, ohne auf ein eigenes Team umzusteigen. Achte darauf, dass Quellcode-Rechte, technische Dokumentation und Infrastruktur-Zugänge von Anfang an vertraglich dir zustehen, nicht nur eine Nutzungslizenz an der fertigen Software. So bleibt das Projekt auch nach Abschluss vollständig in deiner Hand - unabhängig davon, ob du später doch ein internes Team aufbaust oder einen anderen externen Partner beauftragst.

Fazit

Für die meisten KMU-Projekte ist externe Vergabe zum Festpreis die kapitaleffizientere Lösung - vorausgesetzt, die Anforderungen sind sauber dokumentiert. Eine eigene IT-Abteilung lohnt sich erst, wenn Softwareentwicklung zu einer dauerhaften, zentralen Aktivität wird. Und selbst dann schließt das externe Vergabe für einzelne, spezialisierte Projekte nicht aus.

Häufig gestellte Fragen

Wann lohnt sich eine eigene IT-Abteilung für ein KMU?

Eine eigene IT-Abteilung lohnt sich, wenn Software ein dauerhafter, zentraler Teil des Geschäftsmodells ist, etwa bei einem eigenen Produkt, das kontinuierlich weiterentwickelt wird. Für einzelne, klar abgegrenzte Projekte ist externe Vergabe in den meisten Fällen effizienter.

Wie vergleiche ich die Kosten von eigenem Team und externer Vergabe fair?

Zu den Vollkosten einer internen Stelle gehören nicht nur das Bruttogehalt, sondern auch Sozialabgaben, Rekrutierungskosten, Einarbeitungszeit, Ausstattung und Fixkosten unabhängig von der Auslastung. Ein reiner Stundensatz-Vergleich mit externen Angeboten unterschätzt die tatsächlichen Kosten eines internen Teams meist deutlich.

Warum entscheiden sich Unternehmen nach einer gescheiterten externen Vergabe oft für eine eigene IT-Abteilung - und ist das sinnvoll?

Häufig war nicht die externe Vergabe selbst das Problem, sondern fehlende Anforderungsklarheit und ein Vertragsmodell wie Time & Material, das diese Unklarheit nicht abgefedert hat. Mit einem präzisen Anforderungsdokument und einem Festpreisvertrag lassen sich dieselben Probleme meist vermeiden, ohne die hohen Fixkosten eines eigenen Teams in Kauf zu nehmen.

Kann ich ein internes Team und externe Entwicklungspartner gleichzeitig nutzen?

Ja, das ist in der Praxis sogar der Normalfall. Häufige Modelle sind ein kleines internes Kernteam mit externer Vergabe größerer Projekte, oder ein festes internes Team, das punktuell externe Spezialisten für Lastspitzen oder seltenes Spezialwissen hinzuzieht.