Allgemeine Artikel13 min Lesezeit

Was früher Monate kostete: Eigene Werkzeuge für den Mittelstand

Ein Werkzeug, das früher Monate Entwicklungszeit und ein kleines Vermögen kostete, entsteht heute in Wochen. Warum das die Make-or-Buy-Frage im Mittelstand neu stellt – am Beispiel eines Logistikbetriebs.

Jonas HöttlerJonas Höttler
Was früher Monate kostete: Eigene Werkzeuge für den Mittelstand — Allgemeine Artikel

Was früher Monate kostete: Warum der Mittelstand seine Prozesse jetzt selbst digitalisieren sollte

In einem mittelständischen Logistikbetrieb plante über Jahre ein einziger erfahrener Disponent die Touren und kalkulierte die Preise – in gewachsenen Excel-Dateien, die niemand sonst vollständig verstand. Jeden Tag mehrere Stunden, anfällig für Zahlendreher, und vollständig abhängig von einer Person. Fiel sie aus, stand das Verfahren still.

Die naheliegende Lösung wäre ein passendes Werkzeug gewesen: ein kleines Programm, das genau diesen Ablauf abbildet. Sie wurde nie gebaut. Nicht, weil niemand das Problem sah, sondern weil die Rechnung früher klar dagegen sprach. Eine maßgeschneiderte Software bedeutete ein Lastenheft, eine Ausschreibung, eine externe Entwicklung über Monate und schnell eine sechsstellige Summe. Ein großes Standardsystem für Speditionen war zu teuer, zu schwer und passte trotzdem nicht auf den eigenen Ablauf. Also blieb alles, wie es war – die Tabelle, die Überstunden, das Risiko.

Genau diese Rechnung kehrt sich gerade um. Und das ist keine Marketingbehauptung, sondern eine nüchterne Folge dessen, was die Entwicklung kleiner, klar umrissener Software heute kostet. Dieser Artikel macht aus dem anonymisierten Fall ein Argument: Für die wenigen Prozesse, die einen Mittelständler ausmachen, ist der Eigenbau vom Luxus zur rationalen Standardoption geworden.

Die alte Rechnung – und warum sie so lange galt

Über zwei Jahrzehnte folgte die Software-Entscheidung im Mittelstand einem einfachen Dreischritt: Standardsoftware kaufen, wo es sie gibt. Wo nicht, mit der Tabelle leben. Und nur in Ausnahmefällen – wenn das Problem groß genug und die Kasse voll genug war – etwas bauen lassen.

Dieser Reflex war richtig. Eigenentwicklung war teuer, langsam und riskant. Der größte Posten war nie der Code selbst, sondern alles drumherum: Anforderungen klären, ausschreiben, einen Dienstleister finden, Abstimmungsschleifen, Nachträge. Ein Werkzeug, das im Kern eine Tabelle mit Logik war, geriet so leicht zu einem Projekt über zwei, drei Quartale. Bei dünnen Margen ließ sich das selten rechtfertigen.

Fig. 1Der alte Dreischritt – und wo er den Mittelstand stranden ließ
Buchhaltung, Lohn, Standard-CRM
Überall gleich, gut und günstig von Standardsoftware gelöst
kaufen
Branchenübliche Abläufe
Anpassbar über Konfiguration – aber kein Wettbewerbsvorteil
konfigurieren
Der eine Prozess, der euch unterscheidet
Eure Disposition, eure Kalkulation, euer Engpass – nirgends von der Stange erhältlich
selbst bauen
Eigene Darstellung. Die Einordnung in kaufen / konfigurieren / selbst bauen ist qualitativ und dient der Veranschaulichung.

Das Problem lag in der untersten Zeile. Der Prozess, der ein Unternehmen tatsächlich von seinen Wettbewerbern unterscheidet, ist per Definition nicht standardisierbar – sonst wäre er kein Unterschied. Genau dort half Standardsoftware am wenigsten, und genau dort war Eigenbau am teuersten. Der Mittelstand strandete also ausgerechnet bei dem, worauf es am meisten ankam, und behalf sich mit der Tabelle.

Was sich geändert hat

Drei Entwicklungen haben den teuersten Teil der Eigenentwicklung – den Aufwand, der nicht der eigentliche Code ist – zusammenschrumpfen lassen.

Erstens, moderne Bausteine. Authentifizierung, Datenbank, Hosting, Schnittstellen: Was früher Wochen an Grundlagenarbeit bedeutete, ist heute fertiger, bezahlbarer Standard. Ein kleines Team beginnt nicht mehr bei null, sondern bei achtzig Prozent.

Zweitens, KI-gestützte Entwicklung. Assistenzsysteme schreiben, erklären und überprüfen Code mit. In einer kontrollierten Studie von GitHub lösten Entwicklerinnen und Entwickler eine klar umrissene Programmieraufgabe mit Assistenz rund 55 Prozent schneller als ohne. McKinsey kommt in eigenen Experimenten zu vergleichbaren Größenordnungen – mit einer wichtigen Einschränkung, auf die wir gleich zurückkommen.

Drittens, ein anderer Zuschnitt. Statt eines Systems, das alles können soll, baut man ein Werkzeug, das eine Sache richtig macht. Kleiner Zuschnitt heißt weniger Anforderungen, weniger Abstimmung, weniger Risiko – und damit Wochen statt Monate.

Fig. 2Größenordnung: ein fokussiertes internes Werkzeug, früher und heute
Klassisches Projekt: Lastenheft, Ausschreibung, externe Entwicklung26 Wo.
rund ein halbes Jahr bis zum produktiven Einsatz
Fokussiert, moderner Stack, KI-gestützt5 Wo.
Wochen statt Monate – bei eng umrissenem Funktionsumfang
Illustrative Größenordnung für ein klar abgegrenztes Werkzeug, keine Benchmark. Richtung der Produktivität belegt durch kontrollierte Studien zu KI-gestützter Entwicklung (GitHub, McKinsey); siehe Text.

Wichtig ist, was dieses Schaubild nicht behauptet. Es sagt nicht, dass jede Software jetzt in fünf Wochen entsteht. Es sagt: Für ein klar abgegrenztes Werkzeug ist die Größenordnung von Monaten auf Wochen gefallen. Genau in diesem Bereich – kleine, scharf umrissene Werkzeuge – liegt der Engpass des Mittelstands. Und genau dort ist der Hebel am größten.

Warum das gerade jetzt zählt: zwei Schmerzen

Die Kostsenkung wäre eine Randnotiz, träfe sie nicht auf zwei Belastungen, die fast jeder Mittelständler kennt.

Fachkräftemangel. In Deutschland waren laut Bitkom zuletzt rund 109.000 IT-Stellen unbesetzt; 85 Prozent der Unternehmen beklagen einen Mangel, fast vier von fünf erwarten eine weitere Verschärfung. Die Konsequenz für den Mittelstand ist nicht, dass er kein Personal für eine große IT-Abteilung findet – die wollte er ohnehin nie. Sie ist, dass jede Stunde der vorhandenen Leute knapp ist. Software, die manuelle Routine abnimmt, ist hier kein Komfort, sondern die einzige Art, mit gleicher Mannschaft mehr zu schaffen.

Preisdruck. Der DIHK beschreibt die Lage im Mittelstand als geprägt von hohen Kosten, Regulierung und dünnen Margen – in Verkehr und Logistik mit besonders hartem Wettbewerb. Wo die Marge dünn ist, entscheidet Effizienz über den Gewinn. Und Effizienz entsteht selten im Standardprozess, den alle gleich gut beherrschen, sondern im eigenen, den man besser beherrscht als der Wettbewerb.

Fig. 3Der Kontext in drei Zahlen
109.000unbesetzte IT-Stellen in DeutschlandBitkom, 2025
55 %schneller bei einer klar umrissenen Aufgabe mit KI-Assistenzkontrollierte Studie, GitHub
35 %der Mittelständler mit laufenden DigitalprojektenKfW, 2024
Bitkom (unbesetzte IT-Stellen, 2025); kontrollierte GitHub-Studie zur KI-gestützten Entwicklung; KfW-Digitalisierungsbericht Mittelstand 2024.

Der KfW-Wert ist der eigentliche Auslöser für diesen Artikel. Nur gut ein Drittel der Mittelständler hat zuletzt überhaupt Digitalisierungsprojekte umgesetzt; als Hemmnisse nennt die KfW fehlendes Know-how, Infrastruktur und Finanzierung. Übersetzt heißt das: Die meisten lassen Potenzial liegen – nicht aus Unwillen, sondern weil die alte Rechnung in den Köpfen noch gilt. Sie gilt aber nicht mehr.

Die ehrliche Einschränkung

Wer hier nur die Erfolgszahlen zeigt, verkauft Hype. Also die Gegenrechnung, offen auf den Tisch: KI-gestützte Entwicklung macht nicht alles schneller. In einer randomisierten Studie des Forschungsinstituts METR brauchten erfahrene Open-Source-Entwickler mit KI-Werkzeugen für Aufgaben in ihren eigenen, großen und vertrauten Codebasen sogar 19 Prozent länger – während sie selbst glaubten, schneller gewesen zu sein. Auch McKinsey berichtet, dass die Zeitersparnis bei komplexen, unvertrauten Aufgaben auf einen einstelligen Prozentbereich schrumpft.

Das ist kein Widerspruch zur These – es ist ihre Präzisierung. Der Gewinn ist groß bei kleinen, klar umrissenen Aufgaben und verflüchtigt sich, je größer und unvertrauter das System wird. Für eine Konzern-IT, die an einer Millionen-Zeilen-Codebasis arbeitet, ist die KI-Euphorie verfrüht. Für ein mittelständisches Werkzeug, das einen einzelnen Prozess abbildet, trifft sie ins Schwarze. Die Nische, in der der Hebel am größten ist, ist exakt die Nische des Mittelstands.

Fig. 4Wo der Hebel sitzt – und wo der Hype kippt
Zu klein, löst nichts
Fokussiertes Werkzeug
Hier kippt der Hype
Ein SkriptGroßes System
Eigene Darstellung. Produktivitätsgewinne sind bei klar abgegrenzten Aufgaben am größten und schrumpfen mit Komplexität und Unvertrautheit (vgl. McKinsey; METR).

Die praktische Lehre daraus ist eine Disziplin, keine Technologie: klein zuschneiden. Ein Werkzeug, das eine Sache richtig macht, schlägt ein System, das alles ein bisschen kann – nicht trotz, sondern wegen seiner Begrenzung.

Der Fall, zu Ende erzählt

Zurück zu dem Logistikbetrieb. Die Entscheidung war am Ende keine über Technologie, sondern über Zuschnitt. Statt eines Speditionssystems für alles entstand ein Werkzeug für genau einen Ablauf: Touren planen, Preise kalkulieren, das Ergebnis sauber dokumentieren.

Fig. 5Ein Logistikbetrieb, anonymisiert: vom Engpass zum Werkzeug
  1. Der Engpass
    Disposition in der Tabelle
    Ein erfahrener Disponent plant Touren und Preise in gewachsenen Excel-Dateien. Stunden täglich, fehleranfällig, an einer Person hängend.
  2. Die Nicht-Entscheidung
    Zu teuer für einen Eigenbau
    Ein klassisches Projekt hätte Monate und eine sechsstellige Summe bedeutet. Ein großes Standardsystem war Overkill und passte trotzdem nicht. Also blieb alles beim Alten.
  3. Der schlanke Bau
    Ein Werkzeug für genau diesen Prozess
    Kein System für alles, sondern ein fokussiertes Tool für Disposition und Kalkulation – in Wochen statt Monaten, auf modernem, portablem Stack.
  4. Das Ergebnis
    Zeit zurück, Wissen im Haus
    Die manuelle Arbeit schrumpft, das Verfahren steht nicht mehr nur im Kopf einer Person, und die frei gewordene Zeit geht in die Kundenarbeit.
Anonymisierte, verdichtete Darstellung eines realen Projektverlaufs. Keine Kundennennung, keine geprüften Einzelkennzahlen.

Drei Wirkungen sind dabei aufschlussreich, weil sie die beiden Schmerzen direkt adressieren. Die eingesparte Zeit ist eine Antwort auf den Fachkräftemangel – dieselbe Mannschaft schafft mehr. Die schärfere Kalkulation ist eine Antwort auf den Preisdruck – an genau der Stelle, an der die Marge entsteht. Und dass das Verfahren nicht länger nur in einem Kopf steckt, senkt ein Risiko, das in keiner Bilanz steht, aber jeden Inhaber nachts wachhält.

Was das nicht heißt

Damit aus einem Argument keine Ideologie wird, drei klare Grenzen.

Es heißt nicht, alles selbst zu bauen. Buchhaltung, Lohn, E-Mail, das Standard-CRM – kaufen. Wer sein eigenes Buchhaltungssystem schreibt, verwechselt Beschäftigung mit Wertschöpfung. Eigenbau lohnt nur dort, wo Standard nicht passt und der Prozess zum Unterschied beiträgt.

Es heißt nicht, dass Software ein Selbstläufer ist. Ein Werkzeug, das niemand nutzt, ist teurer als die Tabelle, die alle nutzen. Der härteste Teil ist selten der Code, sondern die Einführung: Akzeptanz, Gewohnheit, Vertrauen. Wer das ignoriert, baut ein Denkmal, kein Werkzeug.

Und es heißt nicht, sich in neue Abhängigkeit zu begeben. Ein eigenes Werkzeug ist nur dann ein Vorteil, wenn es euch gehört – mit Datenexport, offenen Formaten und einem Stack, den auch ein anderer weiterpflegen könnte. Sonst tauscht man den Tabellen-Engpass gegen einen Dienstleister-Engpass.

Unsere Haltung

Wir bei balane bauen Software für den Mittelstand – wir beraten, entwickeln und automatisieren, und betrachten jedes Vorhaben durch drei Linsen zugleich: betriebswirtschaftlich, psychologisch und technisch. Am Logistikfall sieht man, warum diese drei zusammengehören. Die betriebswirtschaftliche Linse stellt die Make-or-Buy-Frage ehrlich und sagt auch mal: kaufen, nicht bauen. Die technische Linse sorgt für einen schlanken, portablen Bau ohne Lock-in. Und die psychologische Linse entscheidet darüber, ob das Werkzeug am Ende benutzt wird – oder ob die alte Tabelle heimlich weiterläuft.

Unsere Haltung zum Eigenbau ist deshalb unaufgeregt: Er ist heute selten zu teuer und oft zu naheliegend, um ihn liegen zu lassen – aber nur bei diszipliniertem Zuschnitt und mit klarem Eigentum an Code und Daten. Der Paradigmenwechsel ist nicht, dass plötzlich alles geht. Er ist, dass das eine Werkzeug, das früher an der Rechnung scheiterte, heute durchgeht.

Schlagwörter

Mittelstand · Eigenentwicklung · Digitalisierung · Fachkräftemangel · Make-or-Buy · Prozesse