Internes Tool entwickeln: Wann sich eigene Software lohnt

Das Problem: Der Prozess läuft in Tabellen — und alle wissen, dass das nicht hält

In vielen kleinen und mittleren Unternehmen hängt mindestens ein geschäftskritischer Prozess an einer Konstruktion, die niemand so geplant hat: eine Excel-Datei mit Makros, die nur eine Person versteht. Ein Ordner mit Word-Vorlagen, die per Hand befüllt werden. Eine Standardsoftware, die den Prozess nur zum Teil abbildet — und der Rest wird per E-Mail, Zuruf und Copy-and-paste drumherum organisiert.

Das funktioniert, bis es nicht mehr funktioniert: Die Schlüsselperson ist im Urlaub, zwei Kollegen arbeiten auf verschiedenen Dateiständen, ein Zahlendreher wandert unbemerkt in ein Kundenangebot. Genau an diesem Punkt stellt sich die Frage, ob ein eigenes internes Tool die bessere Lösung ist — und ob sich der Aufwand lohnt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die vor dieser Entscheidung stehen. Er gehört zu unserer Übersicht KI-Softwareentwicklung, Tools und MVPs. Du bist damit übrigens nicht allein: Schon eine repräsentative Bitkom-Befragung von 2017 zeigte, dass 33 Prozent der Unternehmen ab 20 Mitarbeitern eigene Software entwickeln — bei Großunternehmen ab 500 Mitarbeitern waren es 64 Prozent. Eigenentwicklung ist kein Exot, sondern gelebte Praxis, sobald Standardlösungen nicht mehr passen.

Begriffe kurz geklärt

• Internes Tool: Software, die dein Unternehmen für die eigenen Abläufe baut oder bauen lässt — nicht für den Verkauf. Typische Beispiele: ein Planungstool für die Disposition, ein Portal für Auftragsstatus, ein Kalkulationswerkzeug, das die eigene Preislogik abbildet.
• Standardsoftware: Fertige Software für ein Standardproblem (Buchhaltung, E-Mail, CRM). Sie ist günstig pro Nutzer, aber sie bildet deine Besonderheiten nur ab, soweit der Hersteller sie vorgesehen hat. Auch das BSI beschreibt genau diesen Ausgangspunkt: Institutionen brauchen Individuallösungen, wenn sich Herausforderungen „nicht mehr hinreichend mit einem fertigen, unangepassten Softwareprodukt lösen” lassen.
• Low-Code/No-Code: Plattformen, mit denen sich einfache Tools per Baukasten zusammenstellen lassen. Eine sinnvolle Zwischenstufe für simple Formulare und Freigabe-Workflows — mit Grenzen bei komplexer Logik, Integrationstiefe und Datenhoheit.
• MVP (Minimum Viable Product): Die kleinste Version eines Tools, die im Alltag echten Nutzen stiftet. Für interne Tools das richtige Denkmodell: erst der eine Kernprozess, dann der Ausbau.

Abgrenzung: Ein internes Tool ist kein ERP-Ersatz und kein Digitalisierungsprogramm. Es ist ein gezieltes Werkzeug für einen konkreten Prozess, das neben deinen bestehenden Systemen läuft und mit ihnen spricht.

Wann lohnt ein internes Tool?

Die kurze Antwort: wenn drei Bedingungen gleichzeitig erfüllt sind.

1. Der Prozess ist geschäftskritisch oder läuft häufig. Ein Ablauf, der einmal im Quartal vorkommt, rechtfertigt selten eigene Software. Ein Ablauf, der täglich läuft und an dem Umsatz, Liefertermine oder Kundenzufriedenheit hängen, sehr wohl.
2. Standardsoftware passt nachweislich nicht. Nicht „gefällt uns nicht”, sondern: Ihr habt konkrete Anforderungen aufgeschrieben und geprüft, dass keine bezahlbare Standardlösung sie abdeckt — oder die Anpassung der Standardsoftware teurer wäre als ein eigenes Tool.
3. Der Schmerz ist messbar. Doppelte Datenpflege, regelmäßige Fehler, Wartezeiten, Wissen in einem einzigen Kopf. Wenn du den Schaden nicht benennen kannst, kannst du auch den Nutzen des Tools nicht bewerten.

Als Entscheidungshilfe die Matrix, die ich selbst in Erstgesprächen nutze:

Kriterium	Tabelle reicht	Standardsoftware kaufen	Internes Tool entwickeln
Prozess-Häufigkeit	selten, unregelmäßig	regelmäßig, branchenüblich	regelmäßig, firmenspezifisch
Anzahl Nutzer	1–2 Personen	viele, mit Standardbedarf	Team mit Spezialablauf
Logik	einfache Listen/Rechnungen	vom Hersteller vorgesehen	eigene Regeln, Sonderfälle
Datenlage	eine Datenquelle	Insellösung akzeptabel	mehrere Systeme müssen zusammenspielen
Fehlerkosten	gering	mittel	Fehler kosten spürbar Geld oder Reputation
Wettbewerbsrelevanz	keine	keine — Standardproblem	der Prozess ist Teil eures Vorsprungs

Sobald du in der rechten Spalte drei oder mehr Häkchen setzt, ist ein internes Tool ernsthaft prüfenswert. Liegt der Schwerpunkt links oder in der Mitte: Finger weg von Eigenentwicklung — Buchhaltung, E-Mail und Standard-CRM baut niemand sinnvoll selbst nach.

Eine ehrliche Ergänzung aus der Praxis: Die Frage ist selten „Tool ja oder nein”, sondern „welcher Teil des Prozesses zuerst”. Oft löst schon ein kleines Tool für den schmerzhaftesten Teilschritt — etwa die Angebotskalkulation — mehr als ein großes System, das alles können soll.

Welche Nutzer und Prozesse gehören in den Scope?

Der häufigste Fehler passiert vor der ersten Zeile Code: Der Scope wird nach dem Prinzip „wer könnte alles profitieren” geschnitten. Dann sitzen vier Abteilungen am Tisch, jede bringt Wünsche mit, und aus dem Werkzeug wird ein Projekt.

Für die erste Version gilt:

• Ein Prozess. Der mit dem größten, messbaren Schmerz — nicht der prestigeträchtigste.
• Eine primäre Nutzergruppe. Die Menschen, die den Prozess täglich ausführen. Sie definieren, was das Tool können muss, und sie testen es. Führungskräfte, die „auch mal reinschauen wollen”, sind keine primären Nutzer.
• Klare Regeln. Prozesse mit vielen undokumentierten Ausnahmen zuerst aufräumen, dann digitalisieren. Ein Tool, das ein chaotisches Vorgehen abbildet, ist chaotische Software.

Praktisch heißt das: Setz dich mit den zwei, drei Personen zusammen, die den Prozess wirklich ausführen, und lass dir den Ablauf am echten Beispiel zeigen — nicht erzählen, zeigen. Aus meiner Erfahrung weicht der tatsächliche Ablauf fast immer von dem ab, was im Meeting beschrieben wird. Alles, was dabei an weiteren Ideen auftaucht, kommt auf eine schriftliche Später-Liste. Diese Liste ist kein Abstellgleis, sondern das Backlog für Version zwei — bewertet wird sie erst, wenn Version eins produktiv läuft.

Wie vermeidet man ein Großprojekt?

Interne Tools scheitern selten an der Technik. Sie scheitern daran, dass aus „wir brauchen ein kleines Werkzeug” schleichend ein Systemwechsel wird. Vier Regeln dagegen:

1. Zeitbox statt Featureliste. Definiere, was in einer ersten nutzbaren Version nach wenigen Wochen live sein muss — und streiche alles, was nicht hineinpasst. Ein Tool, das nach wenigen Wochen den größten Teil des Schmerzes nimmt, schlägt ein Tool, das erst nach einem Jahr perfekt sein soll.
2. Nicht-Ziele schriftlich festhalten. Ein halbseitiges Dokument: „Dieses Tool ersetzt nicht das ERP. Es bildet nicht die Buchhaltung ab. Es bekommt keine Kundenlogins in Version 1.” Das klingt banal, ist aber das wirksamste Mittel gegen Scope-Creep — jeder neue Wunsch wird gegen dieses Dokument geprüft.
3. Auf Bestehendem aufbauen. Das Tool ergänzt ERP, CRM und Buchhaltung, es ersetzt sie nicht. Sobald jemand vorschlägt, „bei der Gelegenheit” ein Altsystem abzulösen, ist das ein eigenes Projekt mit eigener Entscheidung — nicht Beifang.
4. Ein Vorgehensmodell festlegen — auch im Kleinen. Das klingt nach Konzernbürokratie, ist aber eine Basis-Anforderung des BSI (CON.8.A2): Vorgehen festlegen, Ablaufplan erstellen, daran halten. Für ein KMU-Tool reicht dafür eine Seite: wöchentliche Abstimmung, wer entscheidet, wann getestet wird, wann live gegangen wird. Ohne diese Minimalstruktur entscheidet der Zufall.

KI-gestützte Entwicklung verschiebt hier übrigens die Ökonomie: Erste nutzbare Versionen entstehen heute deutlich schneller als noch vor wenigen Jahren, was kleine, fokussierte Tools zusätzlich attraktiv macht. Sie ersetzt aber weder die Scope-Entscheidung noch Tests und Review — das BSI weist in seinem Papier zu generativen KI-Modellen darauf hin, dass deren Einsatz neuartige IT-Sicherheitsrisiken schafft und eine systematische Risikoanalyse voraussetzt. Wer KI-generierten Code ungeprüft produktiv nimmt, spart am falschen Ende.

Welche Integrationen braucht man?

Die Grundregel: so wenige wie möglich, aber die entscheidenden von Anfang an. Ein internes Tool ohne Anbindung an das führende System erzeugt genau das Problem, das es lösen sollte — eine weitere Insel mit eigener Datenpflege.

Vor dem Start drei Fragen klären:

• Wo liegen die führenden Daten? Kundendaten im CRM, Aufträge im ERP, Artikel im Warenwirtschaftssystem. Das Tool liest diese Daten über Schnittstellen, statt sie zu kopieren. Für jedes Datenfeld muss klar sein, welches System die Wahrheit besitzt.
• Haben die Systeme dokumentierte APIs? Moderne Cloud-Software fast immer, ältere On-Premise-Systeme oft nur eingeschränkt. Das gehört in die Machbarkeitsprüfung, bevor Budget freigegeben wird — eine fehlende Schnittstelle kann den Aufwand vervielfachen.
• Welche Richtung braucht der Datenfluss? Nur lesen ist deutlich einfacher und risikoärmer als schreiben. Für viele erste Versionen reicht Lesen plus ein manueller Rückweg — schreibende Integrationen kommen, wenn sich das Tool bewährt hat.

Auch hier lohnt der Blick in den IT-Grundschutz: CON.8.A6 und A20 fordern, externe Bibliotheken und Komponenten nur aus vertrauenswürdigen Quellen zu beziehen und ihre Integrität zu prüfen. Übersetzt für dein Tool-Projekt: Jede Abhängigkeit — jede Bibliothek, jeder externe Dienst — ist Teil deiner Angriffsfläche und deiner Wartungslast. Weniger ist mehr.

Wie betreibt man es?

Der Betrieb ist der Teil, der in der Euphorie des Bauens am häufigsten vergessen wird — und der darüber entscheidet, ob das Tool in drei Jahren ein Gewinn oder eine Altlast ist. Das Minimum, angelehnt an die Basis-Anforderungen des BSI-Bausteins CON.8:

• Versionsverwaltung mit Backup (CON.8.A10): Der gesamte Code liegt in einem Versionssystem (heute praktisch immer Git), jede Änderung ist nachvollziehbar und rückholbar, das Repository ist gesichert.
• Getrennte Test- und Produktivumgebung (CON.8.A7): Neues wird nie direkt am Live-System ausprobiert — und getestet wird nicht mit echten Kundendaten, wenn es sich vermeiden lässt.
• Updates und Sicherheits-Patches (CON.8.A8): Sicherheitskritische Updates — auch für verwendete Bibliotheken — werden zeitnah eingespielt. Das braucht eine Person, die zuständig ist, und ein kleines, festes Zeitbudget.
• Dokumentation: So viel, dass eine zweite Person das Tool verstehen, betreiben und weiterentwickeln kann. Sonst hast du die Excel-mit-Makros-Situation nur auf höherem Niveau reproduziert.
• Klare Verantwortung: Eine benannte Person (intern oder ein Dienstleister) für Betrieb, Fehler und Weiterentwicklung — mit Vertretungsregel.

Wenn du extern entwickeln lässt: Vereinbare von Anfang an, dass Code, Repository und Dokumentation dir gehören und übergeben werden. Vendor-Lock-in bei einem internen Tool ist vermeidbar — aber nur, wenn du es vor Vertragsschluss regelst.

Kosten und Zeit: ehrliche Bandbreiten

Konkrete Preise ohne Anforderungen sind unseriös, deshalb nur Bandbreiten mit Annahmen aus meiner Projektpraxis: Ein fokussiertes internes Tool — ein Prozess, eine Nutzergruppe, ein bis zwei lesende Integrationen, Web-Oberfläche — liegt typischerweise im niedrigen bis mittleren fünfstelligen Bereich und braucht von Kick-off bis erste produktive Version einige Wochen bis wenige Monate. Mit jeder schreibenden Integration, jeder zusätzlichen Nutzergruppe und jedem Sonderfall wächst beides. Dazu kommen laufende Kosten für Hosting, Updates und kleinere Anpassungen — als Daumenregel solltest du pro Jahr einen spürbaren Anteil der Erstellungskosten für Pflege einplanen, nicht null. Garantierte Einsparungen oder Amortisationszeiten kann dir seriös niemand versprechen; rechne stattdessen selbst: eingesparte Stunden pro Woche mal Stundensatz, plus vermiedene Fehlerkosten, gegen Erstellung und Betrieb.

Risiken und Grenzen

• Das Kopfmonopol wandert mit. Wenn nur eine Person das Tool versteht, hast du das Excel-Problem nicht gelöst. Dokumentation und Vertretung sind Pflicht, keine Kür.
• Standardprobleme selbst nachbauen. Der teuerste Irrweg. Wenn es eine etablierte Lösung gibt, die passt: kaufen.
• Der Prozess ist das Problem, nicht das Werkzeug. Ein schlechter Prozess wird durch Software nicht gut — erst den Ablauf klären, dann bauen.
• Unterschätzter Betrieb. Ein Tool ohne Update- und Backup-Routine wird mit jedem Monat riskanter. Wer den Betrieb nicht stemmen kann, sollte ihn vertraglich an einen Dienstleister geben — oder das Projekt lassen.
• KI-Code ohne Review. Schnell generiert heißt nicht geprüft. Tests, Code-Review und die vom BSI empfohlene Risikobetrachtung gehören auch bei KI-gestützter Entwicklung dazu.

Checkliste: Bist du bereit für ein internes Tool?

Vor der Beauftragung solltest du jede dieser Fragen mit Ja beantworten können:

• Der Zielprozess ist benannt, läuft regelmäßig und der heutige Schmerz ist messbar beschrieben.
• Mindestens zwei Standardlösungen wurden geprüft und passen nachweislich nicht (oder nur mit unverhältnismäßigem Anpassungsaufwand).
• Die primäre Nutzergruppe steht fest und war an der Anforderungsaufnahme beteiligt.
• Es gibt ein schriftliches Nicht-Ziel-Dokument für Version 1.
• Für jedes wichtige Datenfeld ist geklärt, welches System führend ist; die nötigen Schnittstellen existieren nachweislich.
• Die erste nutzbare Version ist auf Wochen, nicht Monate angelegt.
• Budget für den laufenden Betrieb (Hosting, Updates, Pflege) ist eingeplant — nicht nur für die Erstellung.
• Eine Person ist für Betrieb und Weiterentwicklung benannt, mit Vertretung.
• Bei externer Entwicklung: Code, Repository und Doku gehören vertraglich dir.

Wenn zwei oder mehr Punkte offen sind, ist das kein Stoppschild — aber ein klarer Arbeitsauftrag vor dem Start.

Nächster Schritt

Wenn du unsicher bist, ob dein Prozess ein internes Tool rechtfertigt oder wie der Scope geschnitten werden sollte: Genau dafür gibt es unsere KI-Beratung — wir schauen uns den Prozess an und geben dir eine ehrliche Einschätzung, auch wenn sie „kauf lieber Standardsoftware” lautet. Eine bestehende Architektur- oder Scope-Idee prüfen wir ebenfalls; melde dich einfach für ein Erstgespräch. Und wenn dein Team KI-gestützte Entwicklung selbst besser einschätzen können soll, findest du das Passende in unseren Schulungen.

Stand: Juli 2026. Die genannten BSI-Anforderungen beziehen sich auf das IT-Grundschutz-Kompendium, Baustein CON.8 (Edition 2023).