Die meisten Technologiebudgets werden um das herum gebaut, was Kundinnen und Kunden sehen: die Website, die Buchungsstrecke, die App. Was fast nie eine eigene Position bekommt, ist die Software, die das Unternehmen im Hintergrund am Laufen hält — die Tabelle, die den Lagerbestand verfolgt, das geteilte Dokument, das als Aufgabentracker dient, der WhatsApp-Chat, der einen Freigabeprozess ersetzt. Diese internen Tools sind für Kunden unsichtbar, und genau deshalb bleiben sie jahrelang unfinanziert, selbst wenn sie das Unternehmen still mehr kosten als jedes kundenseitige Projekt.
Warum interne Tools den Budgetkampf verlieren
Eine neue Buchungsseite hat einen offensichtlichen Nutzen: mehr Buchungen. Ein Tool, das dem Operations-Team vier Stunden pro Woche spart, hat auch einen Nutzen, aber er lässt sich schwerer beziffern, also verliert es gegen Projekte mit einer sichtbaren Umsatzgeschichte. Das Ergebnis: Unternehmen geben bereitwillig Geld für Kundengewinnung aus, während drei Personen jede Woche manuell dieselben Zahlen in drei verschiedenen Tabellen abgleichen — weil nie jemand beziffert hat, was diese Gewohnheit kostet.
Der manuelle Prozess, der zuerst ersetzt werden sollte
Nicht jede sich wiederholende Aufgabe verdient eine eigene Software — manche sind so, wie sie sind, durchaus in Ordnung. Diejenigen, bei denen sich Handeln lohnt, teilen meist drei Merkmale: Sie kommen häufig vor (täglich oder wöchentlich, nicht einmal pro Quartal), sie betreffen mehr als eine Person, die Informationen weiterreicht, und Fehler darin sind teuer oder peinlich statt trivial zu beheben. Ein seltener, einzeln ausgeführter Prozess mit geringem Risiko lohnt die Automatisierung nicht, selbst wenn er leicht nervt. Ein Prozess, den ein ganzes Team täglich berührt und bei dem ein Fehler eine falsche Bestellung oder einen verpassten Termin bedeutet, ist ein starker Kandidat.
Eine nützliche Übung: Listen Sie jede Stelle auf, an der Informationen derzeit zwischen einer Tabelle, einer Chat-App und dem Gedächtnis einer Person wandern. Jede Übergabe ist eine Stelle, an der Dinge verloren gehen, vergessen werden oder je nach Vertretung anders gehandhabt werden. Die Übergabe, die die sichtbarste Reibung verursacht — diejenige, über die sich am häufigsten jemand beschwert — ist meist der richtige Startpunkt, nicht die technisch interessanteste.
Kleiner Umfang, echter Nutzen
Die internen Tools mit dem besten Nutzen sind selten ehrgeizig. Ein einfaches Formular, das eine Nachrichtenkette ersetzt, ein kleines Dashboard, das Zahlen zieht, die derzeit im Kopf einer Person leben, ein einfaches System, das eine Aufgabe zuweist und verfolgt, statt sich darauf zu verlassen, dass jemand ans Nachfassen denkt — das sind bescheidene Bauten im Vergleich zu einer vollständigen Plattform, und sie amortisieren sich meist schnell, weil die manuelle Version, die sie ersetzen, täglich echte Zeit gekostet hat.
Der Fehler, den es zu vermeiden gilt: ein internes Tool wie eine Mini-Version eines Kundenprodukts zu behandeln, mit demselben Feinschliff und derselben Scope-Ausweitung. Es muss nur zuverlässig für die kleine Zahl an Personen funktionieren, die es nutzen werden, und einfach genug sein, dass das Team tatsächlich dabei bleibt, statt innerhalb eines Monats zurück zur Tabelle zu rutschen.
Das Budget begründen
Interne Tools konkurrieren um Finanzierung mit Projekten, die eine klarere Geschichte haben, daher muss die Begründung in denselben Begriffen erfolgen: eingesparte Stunden pro Woche, multipliziert mit der Zahl der Personen, die die Aufgabe erledigen, verglichen mit den Kosten eines bescheidenen Baus. So gerahmt hat ein kleines internes System oft eine kürzere Amortisationszeit als das kundenseitige Projekt direkt daneben auf der Prioritätenliste — es ist nur weniger sichtbar, sodass niemand die Rechnung aufmacht, wenn ihn niemand darum bittet.
Steht die Begründung, muss der Bau selbst nicht groß sein. Genau solche Projekte hält unser Software-Team bewusst klein, denn ein internes Tool verdient sein Budget dadurch, dass es im Alltag verschwindet, nicht dadurch, dass es beeindruckt. Wenn Sie abwägen, ob Sie dafür eine bestehende Plattform konfigurieren oder etwas Schmales und Individuelles bauen, folgt diese Entscheidung derselben Logik wie in unserem Leitfaden zur Wahl des Software-Wegs — die richtige Antwort hängt meist davon ab, wie standardisiert der Prozess tatsächlich ist.
