Das Gespräch beginnt fast immer gleich. Ein Digital-Transformation-Team eines OEMs betrachtet, wie ihre Rotorblatt-Servicedienstleister Felddaten erfassen, und sagt: „Das könnten wir selbst besser bauen. Wir kennen unsere Prozesse. Wir haben Entwickler. Wie schwer kann das sein?“
Der Instinkt ist nachvollziehbar. Der OEM sieht fragmentierte Daten, die in unterschiedlichen Formaten von verschiedenen Dienstleistern eingehen, weiß genau, wie die Ergebnisse aussehen sollen, und kommt zu dem Schluss, dass eine Eigenentwicklung der direkteste Weg zur Lösung des Problems ist. In manchen Fällen stimmt das. Doch in den meisten Fällen liegen die tatsächlichen Kosten für Entwicklung, Einführung und Wartung einer Contractor-Feldanwendung drei- bis fünfmal höher als die ursprüngliche Schätzung.
Dieser Artikel analysiert, woher diese versteckten Kosten kommen, und bietet einen Entscheidungsrahmen dafür, wann eine Eigenentwicklung sinnvoll ist — und wann nicht.
Der Reiz der Eigenentwicklung
Bevor wir die Kosten betrachten, lohnt es sich anzuerkennen, warum die Eigenentwicklung attraktiv ist. Die Argumente sind real:
- Volle Kontrolle über den Funktionsumfang — das Tool macht genau das, was Sie wollen, nicht mehr und nicht weniger
- Keine Abhängigkeit von einem Anbieter — Sie besitzen den Code, die Roadmap und die Daten
- Maßgeschneiderte Integrationen — die App lässt sich direkt an Ihre internen Systeme anbinden, ohne Middleware
- Geistiges Eigentum — die Software wird zu einem proprietären Vermögenswert
Das sind legitime Vorteile. Die Frage ist nicht, ob sie real sind, sondern ob sie die Gesamtkosten ihrer Realisierung rechtfertigen. Unsere Erfahrung aus über einem Jahrzehnt Zusammenarbeit mit Rotorblatt-Servicedienstleistern zeigt: Die Antwort lautet in der Regel nein — und hier ist der Grund.
Die versteckten Kostenkategorien
1. Feld-spezifische UX ist eine eigene Disziplin
Eine Anwendung für Büroanwender zu entwickeln, ist ein gut verstandenes Problem. Eine Anwendung für Techniker zu entwickeln, die in 80 Metern Höhe am Seil arbeiten, Handschuhe tragen, bei Regen, auf einem Tablet mit zerkratzter Displayschutzfolie — das ist etwas völlig anderes.
Jede Interaktion muss mit einer Hand funktionieren. Schaltflächen müssen groß genug sein, um sie mit Handschuhen zu bedienen. Formulare müssen den Zustand permanent speichern, weil ein Techniker mitten in der Eingabe abgerufen werden kann. Die Fotoaufnahme muss Metadaten automatisch taggen, weil niemand Beschreibungen tippt, während er an einem Rotorblatt hängt. Und all das muss auf einer Vielzahl von Geräten funktionieren — vom neuesten iPad Pro bis zum fünf Jahre alten Samsung-Tablet, das ein Dienstleister in großen Stückzahlen eingekauft hat.
Die Entwicklung einer Enterprise-App kostet typischerweise zwischen 150.000 und 500.000 US-Dollar für den initialen Build2. Eine feldspezifische App mit den oben genannten Anforderungen liegt eindeutig am oberen Ende dieser Spanne — und das vor den Kosten für Nutzerforschung, Feldtests und iteratives Redesign, die ein brauchbares Produkt erfordert.
2. Offline-Modus ist eine monatelange Engineering-Herausforderung
Viele Windparkstandorte haben eingeschränkte oder gar keine Mobilfunkabdeckung. Eine App, die eine permanente Internetverbindung benötigt, ist im Feld nutzlos. Das klingt nach einer einfachen Anforderung: „Einfach die Daten lokal zwischenspeichern und synchronisieren, wenn wieder Netz da ist.“ In der Praxis gehört dies zu den schwierigsten Problemen im Mobile Engineering.
Offline-Modus bedeutet, folgende Herausforderungen zu lösen:
- Konfliktauflösung — was passiert, wenn zwei Techniker denselben Datensatz offline bearbeiten und beide später synchronisieren?
- Datenintegrität — wie stellen Sie sicher, dass keine Datensätze bei der Synchronisation verloren gehen, selbst wenn die App mitten im Upload abstürzt?
- Speichermanagement — Inspektionsfotos sind groß. Eine einzelne Turbinenkampagne kann Gigabytes an Bilddaten erzeugen. Die App muss den lokalen Speicher intelligent verwalten, ohne das Gerät zu füllen.
- Warteschlangenmanagement — die Synchronisation muss Tausende von anstehenden Datensätzen zuverlässig verarbeiten — mit Wiederholungslogik, Fortschrittsanzeige und der Möglichkeit, unterbrochene Uploads fortzusetzen.
Wir haben erlebt, wie im Auftrag von OEMs entwickelte Apps im Vorführraum hervorragend aussahen und bei der ersten Offshore-Kampagne katastrophal versagten, weil die Offline-Architektur nicht praxiserprobt war. Diesen Bereich korrekt umzusetzen, fügt typischerweise drei bis sechs Monate Entwicklungszeit hinzu — zuzüglich dauerhafter Wartungskomplexität.
3. Mehrsprachigkeit ist nicht nur Übersetzung
Der Rotorblatt-Service ist ein globales Geschäft. Dienstleister und ihre Techniker arbeiten in ganz Europa, Amerika, Asien-Pazifik und darüber hinaus. Eine App, die nur auf Englisch funktioniert, wird in Dänemark, Deutschland, Spanien oder Polen nicht akzeptiert. Und Mehrsprachigkeit ist nicht so einfach wie das Übersetzen von Zeichenketten.
Es gilt, Folgendes zu berücksichtigen:
- Dynamisches Umschalten zwischen Sprachen (Techniker arbeiten häufig in gemischtsprachigen Teams)
- Lokalisierungsspezifische Datums-, Uhrzeit- und Zahlenformate
- Anpassungen des UI-Layouts für Sprachen mit längeren Wörtern (deutsche Komposita sprengen jedes für Englisch ausgelegte Layout)
- Fortlaufende Übersetzungspflege bei der Weiterentwicklung von Funktionen
Jede neue Sprache erhöht den Testaufwand. Jede UI-Änderung muss in jeder unterstützten Sprache validiert werden. Das ist kein einmaliger Kostenpunkt, sondern ein permanenter Multiplikator auf jeden künftigen Entwicklungszyklus.
4. Laufende Wartung — hier stecken die wirklichen Kosten
Der initiale Build ist der günstige Teil. Branchen-Benchmarks zeigen durchgängig, dass die jährlichen Wartungskosten 15 bis 20 Prozent des ursprünglichen Entwicklungsbudgets betragen1. Bei einem Build von 400.000 US-Dollar sind das 60.000 bis 80.000 US-Dollar pro Jahr — jedes Jahr, auf unbestimmte Zeit.
Dies umfasst:
- Updates mobiler Betriebssysteme — Apple und Google veröffentlichen jährlich neue Hauptversionen. Jede einzelne kann bestehende Funktionen beeinträchtigen und erfordert Regressionstests sowie Korrekturen über Ihre gesamte Geräteflotte hinweg.
- Sicherheitspatches — eine Contractor-App, die personenbezogene Daten, GPS-Standorte und Informationen zu Kundenstandorten verarbeitet, erfordert kontinuierliche Sicherheitswartung. Eine einzige nicht gepatchte Schwachstelle — und Sie haben einen Datenschutzvorfall.
- Gerätefragmentierung — Dienstleister nutzen eine Mischung aus iOS- und Android-Geräten verschiedener Generationen. Das Testen und Unterstützen dieser Matrix ist ein fortlaufender Aufwand.
- Bugfixes und Nutzerwünsche — sobald die App live ist, hören Feature-Requests und Fehlermeldungen nie auf. Jemand muss sichten, priorisieren, beheben, testen und ausliefern. Das erfordert mindestens einen Vollzeit-Entwickler, oft mehr.
- Testing — jede Änderung, egal wie klein, erfordert Regressionstests über Geräte, Betriebssysteme und Netzwerkbedingungen hinweg (online, offline, intermittierend). Automatisierte Testsuiten müssen aufgebaut und gepflegt werden. Manuelle QA ist erforderlich für feldspezifische Szenarien, die sich im Labor nicht simulieren lassen. Das ist ein permanenter Kostenfaktor, der mit jeder neuen Funktion wächst.
Über fünf Jahre können die gesamten Wartungskosten einer individuellen App die ursprünglichen Entwicklungskosten leicht übersteigen — und das, bevor auch nur eine einzige neue Funktion hinzugefügt wird.
5. Integrationskomplexität summiert sich mit der Zeit
Die App muss Daten mit verschiedenen Drittsystemen austauschen: Schulungsdatenbanken, OEM-Arbeitsauftragssysteme, CRM-Tools, ERP-Systeme und was immer das Unternehmen sonst noch betreibt. Jede Integration ist ein Mini-Projekt: API-Mapping, Authentifizierung, Fehlerbehandlung, Wiederholungslogik, Datentransformation.
Die initiale Integration ist beherrschbar. Die laufenden Kosten sind es nicht. APIs von Drittanbietern ändern sich. ERP-Plattformen bringen neue Versionen heraus. Endpunkte werden abgekündigt. Jede Änderung erfordert, dass Ihr Team recherchiert, aktualisiert, testet und deployt. Bei fünf Integrationen pflegen Sie fünf bewegliche Ziele — parallel zu Ihrer eigenen Codebasis.
6. Die Akzeptanz durch Dienstleister ist der am schwersten zu beziffernde Kostenfaktor
Dies ist das Risiko, das über Erfolg oder Scheitern der gesamten Investition entscheidet. Wenn Dienstleister die App nicht nutzen, ist alles andere irrelevant. Sie haben Hunderttausende Euro in ein Tool investiert, das ungenutzt auf Tablets in Fahrzeugen liegt.
Die Akzeptanz durch Dienstleister scheitert, wenn:
- Die App zu komplex ist (entwickelt von Programmierern, die noch nie in der Höhe gearbeitet haben)
- Die App zu langsam ist (Techniker warten nicht auf Ladescreens zwischen den Turbinen)
- Die App offline nicht funktioniert (siehe oben)
- Die App Arbeitsschritte hinzufügt, ohne sichtbaren Mehrwert für den Techniker (wird als Überwachung statt als Unterstützung wahrgenommen)
- Die Einarbeitung zu lange dauert (Dienstleister wechseln zwischen Kampagnen und können sich keine tagelangen Schulungen leisten)
Spezialisierte Tools lösen das Akzeptanzproblem, weil es ihre einzige Aufgabe ist. Ein Anbieter, dessen gesamtes Geschäftsmodell von der Akzeptanz durch Feldmitarbeiter abhängt, wird mehr in Usability-Forschung, Feldtests und iteratives Design investieren, als jedes interne IT-Team für ein einzelnes Projekt rechtfertigen kann.
Was „Kaufen“ in diesem Kontext bedeutet
Wenn OEMs die „Kaufen“-Option evaluieren, vergleichen sie manchmal mit generischen Field-Service-Plattformen wie ServiceMax, IFS oder den Field-Service-Modulen innerhalb ihres bestehenden ERP. Diese Vergleiche sind nachvollziehbar, aber irreführend. Enterprise-Field-Service-Software ist für Facility Management, Versorgungsunternehmen und Telekommunikation konzipiert. Sie wurde nicht für Rotorblatt-Inspektions-Workflows, Schadensklassifizierung, Seilzugangs-Sicherheitschecks oder OEM-spezifische Arbeitsabfolgen entwickelt.
Die „Kaufen“-Option im Bereich Rotorblatt-Service bedeutet eine Plattform, die speziell für diese Branche gebaut wurde. Eine, die Offline-Modus, Mehrsprachigkeit, OEM-Integrationen und die spezifischen Datenstrukturen, die Rotorblatt-Inspektionen und -Reparaturen erfordern, bereits beherrscht. Eine, deren Roadmap von derselben Branche bestimmt wird, in der Sie tätig sind — nicht von den Anforderungen des Facility Managements oder der Telekommunikation.
Die Wirtschaftlichkeit ist eindeutig. Eine spezialisierte Plattform verteilt ihre Entwicklungskosten auf alle Kunden. Jeder Kunde profitiert von Funktionen, die durch die gesamte Nutzerbasis vorangetrieben werden. Die Kosten pro Nutzer betragen nur einen Bruchteil dessen, was eine Eigenentwicklung erfordern würde — und der OEM erhält ein Produkt, das bereits in realen Kampagnen erprobt ist, keinen Prototypen, der sich erst bewähren muss.
Ein Entscheidungsrahmen
Eine Eigenentwicklung ist sinnvoll, wenn:
- Ihr Prozess wirklich einzigartig ist und kein Anbieter ihn abdeckt (das ist seltener, als die meisten Organisationen glauben)
- Sie ein dediziertes Software-Team mit Erfahrung in Feldanwendungen haben (nicht nur Web-Entwickler)
- Sie bereit sind, die laufende Wartung für mindestens fünf Jahre zu finanzieren
- Sie eine Strategie für die Akzeptanz durch Dienstleister haben, nicht nur für die Einführung
Der Kauf einer Lösung ist sinnvoller, wenn:
- Ihr Kernprozess standardisiert ist (Inspektionen, Reparaturen, Zeiterfassung, Sicherheitschecks), aber Ihre Datenanforderungen spezifisch sind
- Sie in Monaten statt in Jahren live gehen müssen
- Ihre Dienstleister die Plattform bereits nutzen (sofortige Akzeptanz, keine Schulungslücke)
- Sie die Daten besitzen wollen, ohne die Software besitzen zu müssen
- Die Zeit Ihres Engineering-Teams besser in Turbinentechnologie investiert ist als in Contractor-Workflow-Software
Die eigentliche Frage
Die Build-vs-Buy-Entscheidung ist eigentlich keine Technologiefrage. Es ist eine Frage darüber, was zum Kern Ihres Unternehmens gehört — und was nicht. Große OEMs mit globalem Footprint brauchen selbstverständlich eigene Software-Entwicklungskapazitäten. ERP-Systeme, Lieferkettenplattformen und Turbinen-Monitoring-Infrastruktur sind geschäftskritisch und rechtfertigen dedizierte Teams. Aber eine Contractor-Field-Service-Anwendung ist ein anderer Fall. Sie ist ein spezialisiertes, branchenspezifisches Tool, das sich schnell weiterentwickeln muss, unter rauen Feldbedingungen funktionieren muss und die Akzeptanz über eine fragmentierte Dienstleisterbasis erreichen muss, die Ihre Organisation nicht direkt kontrolliert. Das ist keine Frage der Kernkompetenz. Es ist eine Frage der Domänenexpertise — und diese Expertise braucht Jahre der Felderprobung, um sie aufzubauen.
Ihre internen Teams sollten das entwickeln, was Ihre Turbinen am Markt differenziert, nicht das, was die Dienstleister verwaltet, die sie warten. Die gute Nachricht: Das Problem, strukturierte, verlässliche Daten von Contractor-Feldteams zu erhalten, ist bereits von Experten gelöst worden, deren gesamtes Geschäft davon abhängt, es richtig zu machen. Wenn Sie vor dieser Entscheidung stehen, teilen wir gerne, was uns ein Jahrzehnt Entwicklung von Feldsoftware gelehrt hat.
Quellenangaben
- Mehrere Branchenquellen, darunter Noloco, CloseLoop und Cubix, beziffern die jährlichen App-Wartungskosten auf 15–20 % des ursprünglichen Entwicklungsbudgets. Siehe: Custom App Development Cost in 2025 (noloco.io), Mobile App Development Cost Breakdown (cubix.co), Mobile App Development Cost in 2025 (closeloop.com).
- Die Entwicklungskosten für Enterprise-Mobilanwendungen werden branchenweit mit 150.000–500.000+ US-Dollar für komplexe, funktionsreiche Builds angesetzt. Quellen: App Development Costs 2026: Pricing Guide (topflightapps.com), Cost to Develop an Enterprise App in 2025 (syncrasytech.com), Mobile App Development Cost Breakdown (chopdawg.com).