Ein Vertriebsleiter wünscht sich einen zusätzlichen Export für einen Großkunden. Die Geschäftsleitung möchte ein Dashboard für die nächste Sitzung. Ein Kunde fragt nach einer Schnittstelle zu seinem Warenwirtschaftssystem. Jede dieser Bitten ist für sich vernünftig, und mit KI-Werkzeugen lässt sich jede davon in wenigen Tagen umsetzen. Genau darin liegt das neue Problem.
Lange Zeit hat der Aufwand des Programmierens selbst als Filter gewirkt. Was Wochen gekostet hätte, wurde gründlich abgewogen oder gar nicht erst angegangen. Dieser Filter wird schwächer. Wenn Bauen billig wird, verschiebt sich die eigentliche Arbeit: weg von der Frage, wie sich etwas umsetzen lässt, hin zu der Frage, ob es überhaupt gebaut werden sollte.
Warum günstiges Bauen nicht günstiges Besitzen bedeutet
Der Aufwand, eine Funktion zu bauen, ist nur ein kleiner Teil dessen, was sie ein Unternehmen über ihre Lebensdauer kostet. Jede Funktion muss getestet, dokumentiert und erklärt werden. Sie muss bei jeder Änderung am System mitbedacht werden, sie erzeugt Supportanfragen, und sie bindet Aufmerksamkeit in der Oberfläche, die anderen Funktionen fehlt.
KI senkt vor allem die Kosten des ersten Schritts. Die laufenden Kosten sinken deutlich weniger. Ein Team, das heute doppelt so viele Funktionen ausliefern kann, hat in einem Jahr womöglich doppelt so viel zu pflegen – ohne dass sich der Nutzen für die Kunden im gleichen Maß erhöht hätte.
Hinzu kommt ein weniger sichtbarer Effekt: Jede zusätzliche Funktion macht ein Produkt etwas schwerer verständlich. Was für einen Kunden gebaut wurde, sehen alle anderen ebenfalls. Ein Produkt, das vieles kann, wird nicht automatisch besser; oft wird es nur unübersichtlicher.
Woran man Funktionen erkennt, die man besser nicht baut
Es gibt wiederkehrende Muster, bei denen sich ein zweiter Blick lohnt. Keines davon ist ein automatisches Nein, aber jedes ist ein Anlass, genauer nachzufragen.
| Muster | Typisches Signal | Bessere Frage |
|---|---|---|
| Einzelwunsch | Ein Kunde oder eine Person fragt danach | Gibt es dasselbe Problem bei anderen? |
| Lösung statt Problem | Die Anfrage beschreibt eine Funktion, nicht ein Ziel | Was soll am Ende anders sein? |
| Technisch reizvoll | Das Team will es bauen, weil es interessant ist | Wer nutzt es nächste Woche? |
| Vollständigkeit | „Die Konkurrenz hat das auch“ | Verlieren wir Kunden, weil es fehlt? |
| Ausnahmefall | Es betrifft einen seltenen Ablauf | Lässt sich der Fall manuell lösen? |
Besonders die zweite Zeile verdient Aufmerksamkeit. Wer nach einem Export fragt, will in der Regel nicht den Export, sondern eine Zahl in einer anderen Tabelle oder eine Auswertung für eine bestimmte Besprechung. Manchmal lässt sich dieses Ziel ohne neue Funktion erreichen, etwa mit einer bestehenden Auswertung oder einem einmaligen Bericht.
Eine Entscheidungsroutine statt Bauchgefühl
Das Weglassen gelingt selten durch Disziplin allein. Hilfreicher ist eine einfache Routine, die jede neue Anfrage durchläuft, bevor jemand mit der Umsetzung beginnt:
- Das Problem in einem Satz formulieren. Wenn das nicht gelingt, ist die Anfrage noch nicht reif für die Umsetzung.
- Prüfen, wer es sonst noch hat. Ein Problem, das nur eine Person betrifft, ist ein Kandidat für eine manuelle Lösung oder ein persönliches Werkzeug.
- Den Weg ohne Code suchen. Eine Vorlage, eine Anleitung, eine Einstellung oder ein kurzer Prozess im Team lösen erstaunlich viele Anfragen.
- Die Folgekosten benennen. Wer pflegt die Funktion, wer beantwortet Fragen dazu, und was passiert, wenn sie in einem Jahr niemand mehr nutzt?
- Ein Ablaufdatum festlegen. Neue Funktionen bekommen eine Frist, nach der geprüft wird, ob sie genutzt werden. Was die Prüfung nicht besteht, wird wieder entfernt.
Der fünfte Punkt wird in den meisten Unternehmen ausgelassen. Dabei ist das Entfernen einer Funktion genauso eine Produktentscheidung wie das Hinzufügen. Wer es nie tut, sammelt über die Jahre Ballast an, den niemand mehr erklären kann.
Die Liste der Dinge, die man nicht baut
Ein einfaches Werkzeug hat sich in der Praxis bewährt: eine sichtbare Liste der Anfragen, die bewusst abgelehnt oder zurückgestellt wurden, jeweils mit einem Satz Begründung. Sie erfüllt mehrere Zwecke zugleich.
Sie zeigt den Anfragenden, dass ihr Wunsch gehört und abgewogen wurde, statt in einer Warteschlange zu verschwinden. Sie verhindert, dass dieselbe Diskussion alle paar Monate von vorn beginnt. Und sie macht Muster sichtbar: Taucht dieselbe abgelehnte Anfrage immer wieder auf, ist das ein starkes Signal, dass sich die Einschätzung geändert hat und die Entscheidung neu getroffen werden sollte.
Wichtig ist dabei der Ton. Ein „Nein“ auf dieser Liste bedeutet nicht, dass die Idee schlecht war, sondern dass sie im Moment weniger Nutzen bringt als das, woran das Team stattdessen arbeitet.
Ein Beispiel aus dem Mittelstand
Nehmen wir einen Hersteller von Industriekomponenten mit einem Kundenportal, über das Geschäftskunden Bestellungen und Lieferstatus einsehen. Innerhalb eines Quartals gehen drei Anfragen ein: ein Großkunde möchte einen Export im Format seines Einkaufssystems, der Vertrieb wünscht sich eine Übersicht über Kunden mit sinkendem Bestellvolumen, und die Geschäftsleitung möchte im Portal eine Chatfunktion mit einem KI-Assistenten.
Das Team geht die Anfragen mit der Routine durch. Der Export betrifft einen einzigen Kunden; statt einer neuen Portalfunktion erhält er eine wöchentliche Datei, die ein kleines Skript erzeugt. Die Übersicht für den Vertrieb betrifft mehrere Personen und ein klares Ziel – rechtzeitig mit Kunden sprechen, deren Bestellungen zurückgehen. Sie wird gebaut, mit der Vereinbarung, nach drei Monaten zu prüfen, ob sie tatsächlich genutzt wird. Für den KI-Assistenten lässt sich das Problem nicht in einem Satz formulieren. Er kommt auf die Liste der zurückgestellten Vorhaben, mit der Notiz, dass zuerst geklärt werden soll, welche Fragen Kunden heute per Telefon und E-Mail stellen.
Gebaut wurde am Ende eine Funktion statt drei. Die beiden anderen Anfragen sind trotzdem beantwortet: die eine pragmatisch gelöst, die andere mit einem klaren nächsten Schritt versehen.
Was das für Innovationsvorhaben bedeutet
Dieselbe Logik gilt für neue Produkte und Geschäftsfelder. Wenn ein Prototyp in wenigen Tagen steht, ist die Versuchung groß, gleich mehrere Ideen parallel umzusetzen. Sinnvoller ist es, die gewonnene Zeit für die Auswahl zu nutzen: erst prüfen, welche Annahme die riskanteste ist, und dann mit dem günstigsten Test beginnen. Wie das konkret aussehen kann, beschreibt der Beitrag Der billigste Test zuerst.
Auch wenn Fachabteilungen selbst mit KI bauen, hilft die Unterscheidung zwischen dem, was gebaut werden kann, und dem, was betrieben werden soll. Darauf geht der Beitrag Fachabteilung baut mit KI näher ein. Wir arbeiten selbst nach diesem Grundsatz – bei Kundenprojekten ebenso wie bei unseren eigenen Produkten in den drei Labs.
Fazit
KI macht das Bauen von Software schneller und günstiger, aber nicht das Besitzen. Je leichter neue Funktionen entstehen, desto wichtiger wird die Entscheidung, welche davon ein Unternehmen tatsächlich braucht. Eine kurze Routine für neue Anfragen, ein Ablaufdatum für neue Funktionen und eine sichtbare Liste der Dinge, die bewusst nicht gebaut werden, reichen oft aus, um ein Produkt fokussiert zu halten. Wie Unternehmen solche Entscheidungen strukturiert treffen und Ideen prüfen, bevor sie investieren, ist Kern unserer Innovationsberatung.