Ihr kauft Entwicklerstunden. Ihr braucht aber Ergebnisse.

Warum Industrieunternehmen externe IT-Partner anders steuern müssen, wenn aus Projekten tatsächlich Fortschritt entstehen soll.

„Wir brauchen zwei Entwickler für neun Monate.“

Solche Anfragen sind im IT-Geschäft normal, gerade in Industriebetrieben. Das ERP ist über Jahre gewachsen, der Service will endlich ein Kundenportal, die interne IT ist voll und offene Stellen bleiben länger unbesetzt als geplant. Also soll ein externes Team helfen. Daran ist zunächst nichts falsch. Nicht jede Kompetenz muss ein Unternehmen dauerhaft selbst aufbauen, und nicht jedes Thema kann warten, bis intern wieder Luft ist.

Der Fehler steckt meist nicht in der Entscheidung für externe Unterstützung, sondern im Auftrag selbst. Hinter „zwei Entwickler für neun Monate“ steht oft keine klare Antwort auf die wichtigere Frage: Was soll in neun Monaten besser laufen als heute? Soll der Service weniger Zeit mit der Suche nach Ersatzteilen verlieren? Sollen Kunden den Reparaturstatus selbst abrufen können? Soll ein Prozess in der Produktion weniger manuelle Schritte brauchen? Oder geht es vor allem darum, dass ein Fachbereich seit Monaten auf Bewegung wartet?

Wer Entwicklerstunden einkauft, bevor das gewünschte Ergebnis klar ist, kauft oft keine Lösung. Er kauft Zeit, um eine Entscheidung später treffen zu müssen.

Volle Teams sind kein Fortschrittsnachweis

Ein typischer Fall ist das digitale Serviceportal. Die Idee klingt gut: Kunden sollen Dokumentationen, Ersatzteile und Wartungsinformationen schneller finden. Der Vertrieb findet das gut, der Service auch, und die Geschäftsführung hört das Wort Digitalisierung ohnehin gern. Also wird ein Team gebucht, es gibt Workshops, erste Screens und ein wachsendes Backlog.

Nach einigen Wochen liegen trotzdem die entscheidenden Fragen noch auf dem Tisch. Welche Kundengruppe soll zuerst Zugang bekommen? Welche Informationen liegen tatsächlich im ERP und welche nur in Excel-Dateien oder in den Köpfen einzelner Mitarbeiter? Wer entscheidet über Preise, Rollenrechte und Freigaben? Welche Anfragen kosten den Service heute wirklich Zeit? Und welche Funktion würde genau dieses Problem lösen?

Ein externes Team kann Schnittstellen analysieren, Datenmodelle entwerfen und erste Funktionen bauen. Was es nicht kann, ist die fehlende Entscheidung im Unternehmen ersetzen. Wenn dort nicht klar ist, welcher Servicefall zuerst verbessert werden soll und wer fachlich Verantwortung übernimmt, verarbeitet das Projekt nur die Unklarheit professionell weiter. Das Board füllt sich, die Meetings werden länger und die Rechnungen kommen pünktlich. Ob der Service dadurch tatsächlich schneller oder besser wird, kann am Ende trotzdem niemand sauber beantworten.

Das Team ist dann nicht das Problem, ebenso wenig der Vertrag. Problematisch wird es erst, wenn Beschäftigung mit Fortschritt verwechselt wird. Ein voller Kalender und ein ausgelastetes Projektteam beweisen noch nicht, dass sich für Kunden, Service oder Produktion tatsächlich etwas verbessert hat.

Nicht jeder Auftrag braucht dasselbe Vertragsmodell

Der Tagessatz hat einen schlechten Ruf, oft zu Unrecht. Wenn ein Unternehmen noch nicht weiß, wie ein Problem gelöst werden soll, ist Zeit gegen Geld ein ehrliches Modell. Niemand kann seriös einen Fixpreis für ein Vorhaben abgeben, dessen Ziel, Datenlage und technische Abhängigkeiten noch unklar sind. Wer zuerst verstehen muss, wo der eigentliche Engpass liegt, sollte deshalb Orientierung einkaufen.

Das funktioniert aber nur mit einem klar begrenzten Auftrag. Nicht neun Monate Team, sondern sechs Wochen mit einer präzisen Frage: Was müssen wir wissen, um eine belastbare Entscheidung treffen zu können? Das Ergebnis ist dann kein halbfertiges System, sondern ein Lagebild. Welche Daten fehlen? Welche Schnittstellen sind kritisch? Welche Optionen gibt es? Was kostet die Umsetzung grob? Und welches Risiko ist so groß, dass man das Thema besser gar nicht weiterverfolgt?

Sobald das Ziel klarer ist, muss sich auch der Auftrag ändern. Dann wird nicht mehr Orientierung gekauft, sondern ein Ergebnis. Beim Serviceportal könnte das etwa heißen: Servicetechniker sollen die relevanten Informationen für einen Einsatz nicht mehr aus drei Systemen zusammensuchen. Sie sollen sie in einem Ablauf finden und dadurch weniger Zeit verlieren. Das ist keine vollständige Produktstrategie, aber ein konkreter erster Schritt. Er hat einen fachlichen Verantwortlichen, eine messbare Wirkung und einen Zeitpunkt, an dem entschieden werden kann, ob der Ansatz trägt.

Wieder anders sieht es aus, wenn ein System bereits geschäftskritisch ist. Dann geht es nicht mehr um ein Projekt, sondern um Betrieb. Wer reagiert bei einem Ausfall? Wer spielt Sicherheitsupdates ein? Wer dokumentiert Änderungen? Wer kann übernehmen, wenn sich der Dienstleister ändert? Dafür braucht es keine kreative Projektlogik, sondern klare Zuständigkeiten, realistische Service Levels und eine saubere Übergabe.

Orientierung, Umsetzung und Betrieb sind drei unterschiedliche Aufträge. In vielen Unternehmen landen sie trotzdem im selben Satz: „Stellt uns bitte ein Team.“ Genau dort beginnt das Problem.

Ein Projekt braucht einen Auftrag, nicht nur Köpfe

Ein Team wirkt konkret. Zwei Entwickler, eine Projektleitung, vielleicht noch ein Designer. Das lässt sich budgetieren, einkaufen und intern gut kommunizieren. Ein Ergebnis ist anstrengender, weil sich das Unternehmen dafür festlegen muss. Welcher Prozess wird zuerst verbessert? Wer entscheidet auf Kundenseite? Welche Anforderungen können warten? Und woran erkennen wir in drei Monaten, ob sich der Aufwand gelohnt hat?

Diese Entscheidungen lassen sich nicht an eine Agentur delegieren. Sie müssen im Unternehmen getroffen werden. Der externe Partner kann helfen, sie vorzubereiten, Annahmen sichtbar zu machen und technische Konsequenzen zu erklären. Aber er kann nicht dauerhaft die Rolle übernehmen, die intern niemand übernehmen will.

Beim Serviceportal wäre der bessere Start deshalb nicht: „Wir bauen ein Portal.“ Der bessere Start wäre: „Wir wollen den häufigsten digitalen Servicefall unserer Bestandskunden innerhalb von drei Monaten spürbar vereinfachen. Wir messen, ob der Service weniger Anfragen manuell bearbeiten muss. Wenn das nicht funktioniert, bauen wir nicht weiter.“

Der Auftrag wirkt auf den ersten Blick enger. In Wahrheit zwingt er das Unternehmen zu einer besseren Entscheidung. Das externe Team weiß, worauf es hinarbeitet. Der Fachbereich weiß, woran er den Nutzen erkennt. Die Geschäftsführung weiß, wann sie nachsteuern oder aufhören muss. Aus einer technischen Aktivität wird damit ein Vorhaben, das sich auch wirtschaftlich bewerten lässt.

Neue Werkzeuge ändern daran nichts Grundsätzliches. Sie beschleunigen Recherche, Dokumentation, Tests und erste technische Entwürfe. Sie lösen aber keine unklaren Prioritäten, keine fehlende fachliche Verantwortung und keine Projekte, die intern niemand wirklich besitzt. Im Gegenteil: Je schneller ein Team produzieren kann, desto sichtbarer wird, ob es Wirkung liefert oder bloß mehr Arbeit erzeugt.

Der gute Partner macht das Unternehmen handlungsfähiger

Ein guter externer Partner sagt nicht automatisch: „Kein Problem, wir stellen drei Leute.“ Er fragt zuerst, was nach dem Projekt konkret anders laufen soll. Er will wissen, wer auf Kundenseite entscheiden kann, welche Annahme sich in den ersten Wochen bestätigen muss und was dokumentiert wird. Er spricht früh darüber, wem Zugänge und Code gehören und wie ein anderes Team später übernehmen könnte.

Das ist kein Zeichen von Zurückhaltung. Es ist professionell. Ein Partner, der sich nur über Anwesenheit definiert, wird versuchen, möglichst lange gebraucht zu werden. Ein Partner, der Wirkung liefern will, muss das Unternehmen handlungsfähiger machen. Das heißt nicht, dass jede Zusammenarbeit nach drei Monaten endet. Langfristige Partnerschaften sind sinnvoll, wenn Betrieb und Weiterentwicklung zuverlässig organisiert werden müssen. Aber auch dann sollte klar sein, warum diese Zusammenarbeit besteht und welche Verantwortung beide Seiten tragen.

Der beste externe Partner ist nicht jener, der am längsten im Projekt bleibt. Er ist jener, nach dessen Einsatz das Unternehmen besser entscheiden, besser betreiben und besser weiterentwickeln kann als davor.

Unser Future{hacks} Fazit

„Wir brauchen zwei Entwickler für neun Monate“ kann die richtige Antwort sein. Oft ist es aber nur die bequemste Form, einer schwierigeren Frage auszuweichen.

Was soll in neun Monaten besser laufen? Wer trägt intern die Verantwortung? Und woran erkennen wir rechtzeitig, ob wir weitermachen oder stoppen müssen?

Wer darauf keine Antwort hat, sollte noch keine Entwicklerstunden kaufen. Er sollte zuerst sein Problem sauber formulieren.

Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.