Wann Sie mit KI selbst automatisieren und wann besser nicht

Das Problem: Zu viele Projekte, zu wenig klare Entscheidung

Sie haben einen konkreten Automatisierungsbedarf identifiziert, die Geschäftsführung ist bereit zu investieren, und dann kommt die Frage: Bauen wir das selbst, oder holen wir uns Unterstützung? Die meisten Mittelständler beantworten diese Frage emotional. Entweder glaubt die IT, sie könne ohnehin alles besser, oder die Geschäftsführung zögert, weil sie keine externe Abhängigkeit aufbauen will. Beide Reflexe kosten Zeit und Geld.

Die Realität ist nüchterner: Manche Projekte lohnen sich intern, andere nicht. Die Entscheidung hängt weder von Prinzipien noch von der Größe Ihres IT-Teams ab, sondern von messbaren Kriterien. Wer diese systematisch anlegt, spart sich monatelange Experimente mit unklarem Ausgang.

Wann Eigenentwicklung Sinn macht

Eigenentwicklung bedeutet, dass Ihr IT-Team oder ein versierter Fachbereich das Projekt mit eigener Kapazität umsetzt. Das ist dann sinnvoll, wenn Sie vier Voraussetzungen erfüllen:

• Kompetenz: Mindestens eine Person im Team hat bereits vergleichbare Workflows produktiv gebaut, nicht nur Tutorials nachgebaut.
• Kapazität: Sie können die notwendige Zeit freischaufeln, ohne dass Wartung, Support oder laufende Projekte darunter leiden.
• Werkzeuge: Die benötigten Plattformen, APIs und Infrastruktur sind bereits vorhanden oder lassen sich in wenigen Tagen bereitstellen.
• Wartung: Sie haben einen klaren Plan, wer den Workflow nach dem Go-live pflegt, dokumentiert und bei Änderungen anpasst.

Fehlt auch nur einer dieser Punkte, wird aus einem vermeintlich günstigen internen Projekt schnell ein Dauerbaustelle. Besonders die Wartung wird systematisch unterschätzt: Ein Workflow, der einmal läuft, muss bei API-Updates, geänderten Geschäftsprozessen oder neuen Anforderungen angepasst werden. Ohne klare Verantwortung versandet das Projekt nach wenigen Monaten.

Wann Sie extern vergeben sollten

Externe Unterstützung ist kein Eingeständnis von Schwäche, sondern eine Ressourcenfrage. Sie sollten ein Projekt vergeben, wenn mindestens eine der folgenden Bedingungen zutrifft:

• Zeitdruck: Sie brauchen das Ergebnis in weniger als 90 Tagen, und Ihr Team hat parallel andere Verpflichtungen.
• Fehlende Erfahrung: Niemand im Haus hat den gewünschten Use Case schon einmal produktiv umgesetzt.
• Komplexität: Das Projekt berührt mehrere Systeme, erfordert Compliance-Prüfung oder muss rechtssicher dokumentiert werden.
• Nachnutzung: Sie wollen Know-how aufbauen, das über dieses eine Projekt hinausgeht, und erwarten vom Partner expliziten Wissenstransfer.

Ein externer Partner bringt nicht nur Kapazität, sondern auch Erfahrung aus vergleichbaren Projekten. Das reduziert Iterationen und vermeidet typische Anfängerfehler, etwa fehlende Fehlerbehandlung, unzureichende Logging-Strategien oder unsichere API-Schlüssel-Verwaltung.

Kriterien für die Entscheidung

Um die Frage systematisch zu beantworten, legen Sie für jedes Projekt eine Kriterienliste an. Folgende Punkte sollten Sie prüfen:

1. Verfügbare Stunden: Wie viele Stunden pro Woche kann Ihr Team realistisch in das Projekt investieren, ohne dass andere Aufgaben liegen bleiben?
2. Lernkurve: Wie viele Tage dauert es, bis die beteiligten Personen die notwendigen Werkzeuge beherrschen?
3. Risiko: Was passiert, wenn das Projekt scheitert oder sich verzögert? Gibt es vertragliche oder operative Folgen?
4. Skalierung: Wird der Workflow später erweitert, oder ist es eine einmalige Automatisierung?
5. Dokumentation: Haben Sie die Kapazität, den Workflow so zu dokumentieren, dass andere ihn verstehen und anpassen können?

Bewerten Sie jedes Kriterium auf einer Skala von eins bis fünf. Ein Score unter 15 von 25 möglichen Punkten spricht gegen Eigenentwicklung. Wichtig ist, dass Sie die Bewertung schriftlich festhalten und nicht im Nachhinein anpassen, sobald das Projekt läuft.

Rechenbeispiel: Interner Workflow versus Partner

Nehmen wir an, Sie wollen einen Workflow aufbauen, der eingehende Rechnungen per OCR ausliest, gegen Bestelldaten abgleicht und bei Übereinstimmung automatisch in sevDesk bucht. Ihr IT-Mitarbeiter schätzt, dass er für Einarbeitung, Entwicklung und Tests 60 Stunden benötigt. Bei einem internen Stundensatz von 80 Euro ergeben sich 4.800 Euro.

Ein externer Dienstleister bietet Ihnen an, den Workflow in 40 Stunden für 150 Euro pro Stunde umzusetzen, also 6.000 Euro. Darin enthalten sind Dokumentation, Schulung und ein dreiwöchiger Support nach Go-live. Die Differenz beträgt 1.200 Euro.

Nun rechnen Sie die versteckten Kosten ein: Ihr Mitarbeiter verschiebt während der 60 Stunden andere Aufgaben, die entweder liegen bleiben oder später nachgeholt werden müssen. Wenn dadurch Wartungstickets länger offen bleiben oder ein anderes Projekt sich um zwei Wochen verzögert, entstehen zusätzliche Opportunitätskosten. Im Rechenbeispiel nehmen wir an, dass diese Verschiebung intern mit 2.000 Euro bewertet würde. Dann wäre die Eigenentwicklung bei 6.800 Euro, der Partner bei 6.000 Euro.

Zusätzlich liefert der Partner Dokumentation und Know-how-Transfer, sodass Ihr Team den Workflow später selbst warten kann. Intern müssten Sie die Dokumentation selbst erstellen, was weitere zehn Stunden kosten könnte. Im Ergebnis läge die Eigenentwicklung bei rund 7.600 Euro, der Partner bleibt bei 6.000 Euro. Diese Rechnung ist eine Annahme, sie zeigt aber, dass externe Vergabe oft günstiger ist, als es auf den ersten Blick scheint.

Was nicht funktioniert

Drei Strategien sehen wir regelmäßig scheitern:

• Hybrid-Ansatz ohne klare Rollen: Sie starten intern, holen nach Wochen extern Hilfe und müssen dann alles neu aufsetzen, weil die bisherige Arbeit nicht dokumentiert oder nicht wartbar ist.
• Externe Vergabe ohne Anforderungskatalog: Sie beauftragen einen Dienstleister, ohne genau zu definieren, was geliefert werden soll. Das Ergebnis ist technisch korrekt, löst aber nicht Ihr Geschäftsproblem.
• Interne Entwicklung ohne Wartungsbudget: Der Workflow läuft drei Monate, dann ändert sich eine API, und niemand hat Zeit, den Fehler zu beheben. Das Projekt stirbt still.

Alle drei Fehler lassen sich vermeiden, wenn Sie die Entscheidung für oder gegen Eigenentwicklung schriftlich dokumentieren und die Verantwortlichkeiten vor Projektbeginn festlegen.

Wie Sie die Entscheidung treffen

Erstellen Sie für jedes Projekt ein einseitiges Entscheidungspapier. Darin notieren Sie die Kriterien, die Bewertung, die geschätzten Kosten intern und extern sowie die Risiken. Legen Sie fest, wer nach Go-live zuständig ist, und halten Sie die Entscheidung schriftlich fest. Teilen Sie das Papier mit den beteiligten Abteilungen, damit alle denselben Stand haben.

Falls Sie extern vergeben, fordern Sie ein Festpreisangebot mit klarem Lieferumfang, Meilensteinen und Abnahmekriterien. Falls Sie intern bauen, blocken Sie die notwendigen Stunden im Kalender und benennen einen Verantwortlichen, der das Projekt auch nach dem Go-live betreut.

Nächster Schritt

Wenn Sie unsicher sind, ob ein konkretes Projekt intern oder extern besser aufgehoben ist, sprechen Sie mit uns. Wir gehen mit Ihnen die Kriterien durch und helfen Ihnen, eine fundierte Entscheidung zu treffen.

Sprechen Sie mit uns

Sie möchten das in Ihrem Betrieb umsetzen? Wir bauen die passende Maschine mit Ihnen.

Telefon: 040 468 967 680
E-Mail: info@whitefox-automations.com
Oder über unser Kontaktformular.