KI kann einzelne Entwicklungsschritte beschleunigen. Ob Maschinenbauer dadurch Gesamtkosten senken, hängt davon ab, wie Domänenwissen und Softwarekompetenz zusammenspielen.
Dieser Beitrag zeigt, wann erfahrene Architekten eines spezialisierten Partners sinnvoll ergänzen und welche Kosten und Risiken beim Vergleich interner und externer Umsetzung zählen. Maschinenbauer behalten dabei ihr Produkt- und Prozesswissen im Unternehmen.
Lange galt die Annahme, dass individuelle Software ein eigenes Entwicklerteam erfordert. Mit generativer künstlicher Intelligenz (GenAI) entsteht die Hoffnung, dass Fachbereiche Anwendungen selbst entwickeln können, weil Werkzeuge wie Copilot, Claude oder ChatGPT Programmcode erzeugen.
Diese Schlussfolgerung greift zu kurz. Vibe Coding bezeichnet einen KI-gestützten Entwicklungsstil, bei dem Code hauptsächlich durch natürlichsprachige Eingaben entsteht. Eine produktionsreife Anwendung entsteht aber nicht allein dadurch, dass Code schneller geschrieben wird. Auch Architektur, Sicherheit, Tests, Deployment, Betrieb und langfristige Wartbarkeit müssen zusammenpassen.
Damit verschiebt sich die eigentliche Frage. Es geht nicht nur darum, wer Code erzeugen kann, sondern wer mit vertretbarem Aufwand sichere, wartbare und langfristig betreibbare Software liefert.
Diese Unterscheidung ist im Maschinenbau besonders wichtig. Software ist dort häufig eng mit Maschinen, Steuerungen, Produktionsdaten, Cloud-Plattformen und der Unternehmens-IT verbunden. Fehler betreffen deshalb nicht nur eine Benutzeroberfläche, sondern können Verfügbarkeit, Serviceprozesse und Cybersecurity beeinflussen.
Sobald eine Anwendung über Jahre betrieben und weiterentwickelt werden soll, müssen unter anderem folgende Fragen beantwortet werden:
Wenn KI mehr Code erzeugt, bleibt es entscheidend, diesen Code zu prüfen, zu integrieren, abzusichern und langfristig zu warten. Auch deshalb bleiben erfahrene Softwarearchitekten und Software Engineers wichtig. Allerdings müssen diese Rollen nicht dauerhaft in voller Stärke beim Maschinenbauer beschäftigt sein. Welche Pflichten aus CRA und NIS2 folgen, hängt unter anderem davon ab, ob ein konkretes Produkt oder Unternehmen in ihren jeweiligen Anwendungsbereich fällt.
Ein internes Team besitzt einen entscheidenden Vorteil: Es kennt Maschinen, Prozesse, Produkte und Kunden. Dieses Wissen ist unverzichtbar und sollte im Unternehmen bleiben. Daraus folgt jedoch nicht, dass auch sämtliche technischen Spezialkompetenzen dauerhaft intern aufgebaut werden müssen.
Professionelle Softwareentwicklung benötigt je nach Vorhaben unterschiedliche Kompetenzen, beispielsweise Architektur, Backend- und Frontend-Entwicklung, Cloud und DevOps, Security sowie Testing. Diese Kompetenzen werden nicht in jeder Projektphase gleich stark benötigt. Ein Maschinenbauer muss sie jedoch rekrutieren, einarbeiten, weiterbilden und auslasten, wenn er das vollständige Team selbst aufbauen will.
Hinzu kommt ein praktisches Problem. Die vorhandenen Mitarbeiter sind häufig bereits durch Produktentwicklung, Kundenprojekte, Service und Tagesgeschäft gebunden. Selbst wenn grundsätzlich technisches Know-how vorhanden ist, fehlt oft die konzentrierte Kapazität für eine konsequente Modernisierung oder Neuentwicklung. Fehlendes Spezialwissen muss parallel zum Projekt aufgebaut werden. Dadurch verlängern sich Laufzeit und Time-to-Market.
Der Kostentreiber ist deshalb nicht nur das Gehalt. Entscheidend sind auch Recruiting, Einarbeitung, Lernkurven, Verzögerungen, Opportunitätskosten und das Risiko, dass ein nur teilweise verfügbares Team eine Lösung über längere Zeit neben dem Tagesgeschäft entwickelt.
Aus diesen Rahmenbedingungen kann sich ein Partnermodell ergeben, das die Stärken beider Seiten verbindet. Der Maschinenbauer bleibt fachlich in der Verantwortung. Der Softwarepartner ergänzt gezielt die technischen Kompetenzen und Kapazitäten, die für eine professionelle Umsetzung benötigt werden.
| Maschinenbauer bringt ein | Softwarepartner bringt ein |
|---|---|
| Maschinen-, Prozess-, Produkt- und Kundenwissen | Softwarearchitektur und Software Engineering |
| Prioritäten und Produktverantwortung | Cloud, DevOps und automatisierte Bereitstellung |
| Fachliche Abnahme und Anwenderfeedback | Security, Testing und Qualitätsstandards |
| Strategische Kontrolle über die Lösung | Temporär skalierbare Spezialisten und Umsetzungskapazität |
Erfahrene Spezialisten können Architektur- und Engineering-Kompetenz mit KI-gestützten Werkzeugen kombinieren. Ob dadurch dasselbe Ergebnis mit weniger Personentagen erreicht wird, muss das jeweilige Projekt zeigen. Der Maschinenbauer kann so auf seltene Rollen zugreifen, ohne sie zwingend dauerhaft selbst vorzuhalten.
Ein Maschinenbauer modernisiert im Musterprojekt eine Serviceanwendung. Leistungsumfang sowie Qualitäts- und Abnahmekriterien bleiben in allen Varianten gleich. Für die technische Umsetzung einschließlich Architektur, Tests und Integration veranschlagen wir 2.400 Personenstunden. Teamtermine fallen in allen Varianten zusätzlich an.
Nach Abzug der Teamtermine stehen drei internen Personen im Modell 208 Umsetzungsstunden pro Monat zur Verfügung, drei externen Personen 416 Stunden. Der geschätzte Aufwand geteilt durch diese Kapazität ergibt die Laufzeit. Externe Partner ergänzen damit nicht nur Kapazität, sondern auch Engineering-Erfahrung, die intern erst aufgebaut werden müsste.
| Modell | Team | Aufwand | Laufzeit | Teamtermine je Sprint / gesamt | Teamaufwand gesamt | Ø-Stundensatz | Gesamtkosten |
|---|---|---|---|---|---|---|---|
| Intern | 3 × 50 % | 2.400 h | 11,54 Monate | 24 h / 600 h | 3.000 h | 51,42 €/h | 154.259 € |
| Extern | 3 × 90 % | 2.400 h | 5,77 Monate | 24 h / 300 h | 2.700 h | 110 €/h | 297.000 € |
| Extern, kleiner | 2 × 90 % | 2.400 h | 8,65 Monate | 16 h / 300 h | 2.700 h | 110 €/h | 297.000 € |
| Nearshore | 1 extern + 4 Nearshore, je 90 % | 2.400 h | 3,46 Monate | 40 h / 300 h | 2.700 h | 70 €/h | 189.000 € |
| Nearshore, kleiner | 1 extern + 2 Nearshore, je 90 % | 2.400 h | 5,77 Monate | 24 h / 300 h | 2.700 h | 76,67 €/h | 207.000 € |
Das Fünferteam ist rechnerisch am schnellsten; das kleinere Nearshore-Team erreicht dieselbe Laufzeit wie das dreiköpfige externe Team, aber zu geringeren Kosten. Weniger externe Personen senken hier den monatlichen Budgetbedarf, nicht automatisch die Gesamtkosten. Die Rechnung unterstellt gut parallelisierbare Arbeit und berücksichtigt keine Urlaubs- oder Ausfallzeiten. Die Laufzeiten sind deshalb Modellwerte, keine Terminprognosen.
Alle Stunden sind Personenstunden. Ein einstündiger Termin mit drei Personen verursacht drei Personenstunden. Die 2.400 technischen Stunden sind eine Beispielannahme, kein Messwert oder Marktbenchmark. Für alle Varianten setzen wir denselben technischen Aufwand an; zusätzlicher Wissensaufbau wird nicht separat kalkuliert.
Übersicht und Details verwenden dieselbe Rundung. Geldbeträge sind auf volle Euro gerundet, Stundensätze, Monate und Sprints auf zwei Nachkommastellen. Stunden zeigen Nachkommastellen nur, wenn sie benötigt werden. Alle Berechnungen verwenden ungerundete Werte, nicht die gerundeten Tabellenangaben.
Für alle Personen setzen wir einheitlich 40 Vertragsstunden pro Woche an. Mit vereinfachend 52 Wochen und 12 Monaten pro Jahr ergeben 40 h/Woche × 52 Wochen ÷ 12 Monate rund 173,33 Vertragsstunden pro Person und Monat. Das sind rechnerische Vertragsstunden, keine um Urlaub, Feiertage und Krankheit bereinigten Arbeitsstunden. Solche Abwesenheiten würden die verfügbare Kapazität reduzieren und die Laufzeit verlängern.
Intern stehen vor Teamterminen 50 Prozent der Vertragsstunden für das neue Projekt zur Verfügung; die übrigen 50 Prozent bleiben für das Tagesgeschäft. Extern und Nearshore sind vor Teamterminen 90 Prozent für das Projekt vorgesehen; die übrigen 10 Prozent bleiben für interne Aufgaben und Puffer. Diese Projektanteile sind Annahmen, keine allgemeingültigen Auslastungswerte.
Je Person und zweiwöchigem Sprint rechnen wir mit acht Stunden Teamterminen. Das sind zwei Stunden Planung, zehn Daily Scrums zu je 15 Minuten, eine Stunde Review, eine Stunde Retrospektive und 1,5 Stunden Refinement. Das Modell unterstellt dieselbe Terminteilnahme unabhängig vom Projektanteil. 52 Wochen ÷ 2 Wochen ergeben 26 Sprints pro Jahr; 8 Stunden × 26 Sprints ÷ 12 Monate ergeben rund 17,33 Termin-Stunden pro Person und Monat. Für drei Personen fallen 24 Personenstunden pro Sprint an, für zwei Personen 16 und für fünf Personen 40.
Die Netto-Kapazität pro Monat berechnet sich als Teamgröße × (40 h/Woche × 52 Wochen ÷ 12 Monate × Projektanteil − 8 h × 26 Sprints ÷ 12 Monate). Die Laufzeit ergibt sich aus Projektaufwand geteilt durch diese Netto-Kapazität. Die Anzahl der Sprints entspricht der Laufzeit in Monaten × 52 Wochen ÷ 12 Monate ÷ 2 Wochen pro Sprint. Der gesamte Terminaufwand ist die Sprintanzahl × Teamgröße × acht Stunden. Gleichwertig kannst du die Laufzeit in Wochen durch zwei teilen und mit den Teamstunden je Sprint multiplizieren. Der gesamte Teamaufwand ist Projektaufwand plus Terminaufwand. Angefangene Sprints werden anteilig gerechnet, nicht auf volle Sprints aufgerundet.
| Modell | Netto-Kapazität pro Monat | Aufwand | Laufzeit | Sprints | Teamtermine je Sprint | Teamtermine gesamt | Teamaufwand gesamt | Ø-Stundensatz | Gesamtkosten |
|---|---|---|---|---|---|---|---|---|---|
| Intern | 208 h | 2.400 h | 11,54 Monate | 25,00 | 24 h | 600 h | 3.000 h | 51,42 €/h | 154.259 € |
| Extern | 416 h | 2.400 h | 5,77 Monate | 12,50 | 24 h | 300 h | 2.700 h | 110 €/h | 297.000 € |
| Extern, kleiner | 277,33 h | 2.400 h | 8,65 Monate | 18,75 | 16 h | 300 h | 2.700 h | 110 €/h | 297.000 € |
| Nearshore | 693,33 h | 2.400 h | 3,46 Monate | 7,50 | 40 h | 300 h | 2.700 h | 70 €/h | 189.000 € |
| Nearshore, kleiner | 416 h | 2.400 h | 5,77 Monate | 12,50 | 24 h | 300 h | 2.700 h | 76,67 €/h | 207.000 € |
Die gleichen 300 Terminstunden der externen Varianten sind kein pauschaler Zuschlag. Drei externe Personen benötigen 12,5 Sprints × 24 Stunden, zwei Personen 18,75 Sprints × 16 Stunden und das Fünferteam 7,5 Sprints × 40 Stunden. Dass alle drei Rechnungen denselben Wert ergeben, folgt aus dem gleichen Projektanteil und der unterstellten linearen Verteilung der Arbeit. Zusätzliche Koordination größerer Teams, Wartezeiten und nicht parallelisierbare Aufgaben könnten diesen Zusammenhang verändern.
Für die interne Modellrechnung nehmen wir 6.301 Euro Monatsbrutto für 40 Wochenstunden an. Den Entgeltatlas der Bundesagentur für Arbeit kannst du nutzen, um die Gehaltsannahme für Beruf und Region abzugleichen; seine Vollzeitentgelte legen keine einheitliche 40-Stunden-Woche fest. Auf das Brutto rechnen wir pauschal 23 Prozent Arbeitgeberkosten, Faktor 1,23, und anschließend 15 Prozent Gemeinkosten, Faktor 1,15. Beide Zuschläge sind Modellannahmen, keine allgemeingültigen gesetzlichen Sätze. 6.301 × 12 × 1,23 × 1,15 ÷ (40 × 52) ergeben gerundet 51,42 Euro je Vertragsstunde.
Für externe Rollen setzen wir 110 Euro je Stunde und für Nearshore-Rollen 60 Euro je Stunde an. Beide Sätze sind Modellannahmen, keine verifizierten Marktpreise oder Angebote. Für gemischte Teams unterstellen wir gleich viele abrechenbare Stunden aller Teammitglieder. Der gewichtete Satz für eine externe und vier Nearshore-Rollen ist (110 + 4 × 60) ÷ 5 = 70 Euro je Stunde. Für eine externe und zwei Nearshore-Rollen ergibt sich (110 + 2 × 60) ÷ 3, gerundet 76,67 Euro je Stunde.
Die Gesamtkosten berechnen sich als Teamaufwand gesamt × gewichteter Stundensatz. Extern werden nur Projektarbeit und Teamtermine abgerechnet, nicht die zehn Prozent interne Zeit. Intern werden nur die dem Projekt zugerechneten Personal- und Gemeinkosten ausgewiesen; die Kosten des übrigen Tagesgeschäfts fallen weiterhin an. Interne Projektkosten sind deshalb nicht mit zusätzlichen Auszahlungen oder unmittelbar einsparbaren Gehältern gleichzusetzen.
Die ausgewiesenen Kosten enthalten keine Umsatzsteuer. Produktverantwortung und fachliche Abnahme beim Maschinenbauer, zusätzliches Onboarding, Recruiting, separat beschaffte Projektinfrastruktur und späterer Betrieb sind nicht eingerechnet. Auch der wirtschaftliche Nutzen einer früheren Fertigstellung ist nicht beziffert.
Für die KI-Szenarien verwenden wir das Team aus einer externen und zwei Nearshore-Rollen. Ohne KI umfasst die Umsetzung geschätzt 2.400 Stunden, dauert rechnerisch 5,77 Monate und kostet 207.000 Euro. Alle drei Personen nutzen KI mit einem angesetzten Budget von jeweils 500 Euro pro Monat, zusammen 1.500 Euro monatlich. Die angesetzten KI-Kosten sinken mit der Laufzeit; die Prozentwerte unterstellen eine Nettoersparnis nach Prüfung und Nacharbeit.
In einer Untersuchung von Microsoft Research von 2023 benötigten Entwickler mit GitHub Copilot für eine konkrete JavaScript-Aufgabe im Durchschnitt 55,8 Prozent weniger Bearbeitungszeit. Die Studie untersuchte keinen vollständigen Maschinenbauprojektzyklus. Der davon inspirierte 55-Prozent-Fall ist deshalb ein optimistisches Rechenbeispiel, keine Prognose für dein Projekt.
| Weniger technische Stunden | Verbleibender Aufwand | Laufzeit | Teamtermine | KI-Budget gesamt | Gesamtkosten | Effekt gegenüber ohne KI |
|---|---|---|---|---|---|---|
| 0 % | 2.400 h | 5,77 Monate | 300 h | 8.654 € | 215.654 € | 8.654 € Mehrkosten |
| 10 % | 2.160 h | 5,19 Monate | 270 h | 7.788 € | 194.088 € | 12.912 € Ersparnis |
| 25 % | 1.800 h | 4,33 Monate | 225 h | 6.490 € | 161.740 € | 45.260 € Ersparnis |
| 35 % | 1.560 h | 3,75 Monate | 195 h | 5.625 € | 140.175 € | 66.825 € Ersparnis |
| 55 % | 1.080 h | 2,60 Monate | 135 h | 3.894 € | 97.044 € | 109.956 € Ersparnis |
Der Kosten-Break-even liegt im Modell bei rund 4,01 Prozent weniger technischem Aufwand. Die 0-Prozent-Zeile enthält KI-Kosten ohne Entlastung und ist nicht mit der Variante ohne KI gleichzusetzen. Ob KI tatsächlich Aufwand spart, muss das jeweilige Projekt messen; auch Mehraufwand ist möglich.
Teamgröße, Projektanteile, Terminteilnahme, Stundensätze und Rundung entsprechen Abschnitt 5. Die 500 Euro je Person und Monat sind eine Budgetannahme für KI-Lizenzen und Nutzung, kein Preis eines bestimmten Produkts. Das Modell behandelt das Budget als vollständig verbraucht und rechnet es für alle drei Personen dem Projekt zu. Angefangene Monate werden zeitanteilig angesetzt, nicht auf volle Abrechnungsmonate aufgerundet.
Die Prozentwerte beziehen sich nur auf die 2.400 technischen Stunden des Projektumfangs. Sie sind angenommene Nettoeinsparungen nach zusätzlicher Prüfung, Integration und Nacharbeit, keine aus der Studie abgeleiteten Projektprognosen. Die Termine je Sprint werden durch KI nicht kürzer. Ihr Gesamtaufwand sinkt nur deshalb, weil weniger Sprints benötigt werden.
Die Netto-Kapazität bleibt bei 3 × (40 h/Woche × 52 Wochen ÷ 12 Monate × 0,9 Kapazität − 8 Terminstunden/Sprint × 26 Sprints ÷ 12 Monate) = 416 Stunden pro Monat. Der verbleibende technische Aufwand ist 2.400 Stunden × (1 − angenommene Reduktion). Die Laufzeit ist dieser Aufwand geteilt durch 416 Stunden pro Monat. Die Sprintanzahl ist die Laufzeit in Monaten × 52 Wochen ÷ 12 Monate ÷ 2 Wochen pro Sprint; die gesamten Teamtermine sind Sprintanzahl × 3 Personen × 8 Stunden. Der Teamaufwand ist technische Arbeit plus Teamtermine. Die Teamkosten sind Teamaufwand × ((110 + 2 × 60) ÷ 3). Die KI-Kosten sind 3 × 500 Euro × ungerundete Laufzeit in Monaten. Die Gesamtkosten sind Teamkosten plus KI-Kosten. Die Ersparnis vergleicht diese Gesamtkosten mit 207.000 Euro für dasselbe Team ohne KI.
| Reduktion | Technische Stunden | Laufzeit | Sprints | Teamtermine je Sprint | Teamtermine gesamt | Teamaufwand | Teamkosten | KI-Budget gesamt | Gesamtkosten | Effekt gegenüber ohne KI |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 % | 2.400 h | 5,77 Monate | 12,50 | 24 h | 300 h | 2.700 h | 207.000 € | 8.654 € | 215.654 € | 8.654 € Mehrkosten |
| 10 % | 2.160 h | 5,19 Monate | 11,25 | 24 h | 270 h | 2.430 h | 186.300 € | 7.788 € | 194.088 € | 12.912 € Ersparnis |
| 25 % | 1.800 h | 4,33 Monate | 9,38 | 24 h | 225 h | 2.025 h | 155.250 € | 6.490 € | 161.740 € | 45.260 € Ersparnis |
| 35 % | 1.560 h | 3,75 Monate | 8,13 | 24 h | 195 h | 1.755 h | 134.550 € | 5.625 € | 140.175 € | 66.825 € Ersparnis |
| 55 % | 1.080 h | 2,60 Monate | 5,63 | 24 h | 135 h | 1.215 h | 93.150 € | 3.894 € | 97.044 € | 109.956 € Ersparnis |
Ohne Nettoeinsparung ergeben sich 1.500 × (2.400 ÷ 416), gerundet 8.654 Euro KI-Kosten, zusätzlich zu 207.000 Euro Teamkosten. Der Kosten-Break-even ergibt sich aus (1.500 × 2.400 ÷ 416) ÷ (207.000 + 1.500 × 2.400 ÷ 416), also rund 4,01 Prozent. Er gilt nur bei den unveränderten Kapazitäts- und Abrechnungsannahmen dieses Modells.
Die Studie untersuchte die Implementierung eines HTTP-Servers in JavaScript, nicht die Gesamtwirkung auf Architektur, Betrieb oder langfristige Softwarequalität. Auch interne und andere externe Teams können KI einsetzen; hier wird lediglich der Effekt für das gewählte Nearshore-Team isoliert.
Ein Partner muss das Domänenwissen zunächst verstehen. Abstimmung, Onboarding und Übergabe kosten Zeit, und ein Anbieterwechsel kann trotz guter Dokumentation Aufwand verursachen. Bei dauerhaft hoher Auslastung und vorhandenem internem Know-how kann ein eigenes Team deshalb wirtschaftlicher sein. Das Partnermodell passt eher, wenn spezialisierte Kompetenzen nur zeitweise benötigt werden oder intern nicht rechtzeitig verfügbar sind.
Eine Zusammenarbeit sollte transparent und übergabefähig organisiert sein:
So bleibt das Domänen- und Produktwissen im Unternehmen, während technische Kompetenz flexibel ergänzt wird. Das gelingt aber nur, wenn Zuständigkeiten, Übergaben und Wissenstransfer aktiv gesteuert werden.
KI macht externe Softwareentwicklung nicht überflüssig. Sie verändert vielmehr deren Wirtschaftlichkeit. Maschinenbauer benötigen weiterhin internes Produkt-, Prozess- und Maschinenwissen. Sie müssen jedoch nicht jede Rolle der modernen Softwareentwicklung dauerhaft selbst aufbauen und auslasten.
Eine mögliche Kombination besteht aus einem fachlich verantwortlichen Team beim Maschinenbauer, erfahrenen Softwarearchitekten und Software Engineers beim spezialisierten Partner sowie einem kontrollierten Einsatz generativer KI. Ob dadurch die benötigte Engineering-Kapazität sinkt, hängt von Aufgaben, Team und Qualitätsanforderungen ab.
Vergleiche deshalb Gesamtkosten und Risiken für den konkreten Leistungsumfang. Berücksichtige dabei auch interne Kapazitäten, Einarbeitung, Koordination, Wissenstransfer und späteren Betrieb.
Wie verteilt ihr Domänenwissen und Softwarekompetenz in euren Projekten? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.
Weitere Artikel zu ähnlichen Themen.
