Am Tisch fehlt, wer nach der Demo Verantwortung trägt

9 Min. Lesezeit

Ein Tool macht aus Software keine reine Konfiguration

Die Runde wirkt gewöhnlich bestens aufgestellt. Prozessverantwortliche beschreiben den Ablauf. Ein Anbieter erklärt die Plattform. Jemand aus der IT fragt nach Zugriffsrechten. Ein Projektmanager pflegt den Zeitplan. Ein Berater verwandelt Meinungsverschiedenheiten in eine Workshop-Übung. Alle nicken das Diagramm ab.

Dann fällt der verhängnisvolle Satz: „Das ist größtenteils Konfiguration.“

Dieser Satz hat Unternehmen absurd viel Geld gekostet.

Er klingt bescheiden, praktisch und nicht technisch. Er vermittelt dem Management, das Projekt sei gar kein richtiges Software-Vorhaben. Es sei die Einführung eines Tools, die Umsetzung eines Workflows, eine Digitalisierungsinitiative, ein Automatisierungsprogramm, eine Dokumentationsbereinigung mit ein wenig KI am Rand.

Schöne Worte. Falsches Risikomodell.

Wenn ein Projekt die Arbeitsweise verändert, Entscheidungen weiterleitet, Daten umformt, Aktionen auslöst, Zustände speichert, Ausnahmen behandelt und zu etwas wird, auf das Menschen täglich angewiesen sind, dann ist es Software-Arbeit. Vielleicht entsteht sie auf einer Plattform. Vielleicht wird sie über eine grafische Oberfläche konfiguriert. Vielleicht beschleunigt KI die Arbeit. Vielleicht steht kein traditionelles Entwicklungsteam daneben. Nichts davon ändert die zugrunde liegende Realität.

Jemand entscheidet weiterhin über das Verhalten.

Jemand bildet weiterhin Annahmen in Regeln ab.

Jemand erzeugt weiterhin Fehlerbilder.

Die Frage ist, ob irgendjemand im Raum weiß, wie diese Fehler aussehen, bevor das Unternehmen von der Software abhängig wird.

Das alte Versprechen kehrt immer wieder zurück

Der aktuelle Glaube, Automatisierungs-Tools und KI ließen Menschen ohne technischen Hintergrund zuverlässige Geschäftssysteme bauen, ist nicht neu. Es ist ein altes Versprechen mit besseren Demos.

COBOL sollte betriebliche Programmierung lesbarer und zugänglicher machen. Das war nicht töricht. Es war ein ernsthafter Versuch, die Sprache des Geschäfts näher an die Datenverarbeitung zu bringen. Aber COBOL beseitigte nicht den Bedarf an Urteilsvermögen in Softwarefragen. Es brachte riesige Systeme hervor, die jahrzehntelang Gehaltsabrechnung, Banken, Versicherungen, Logistik und Behörden betrieben. Viele laufen noch immer, weil einmal eingebettete Geschäftslogik zur Infrastruktur wird.

Visual Basic trug ein ähnliches Versprechen in die Desktop-Ära. Formulare bauen. Daten anbinden. Büroarbeit automatisieren. Menschen aus den Fachbereichen Anwendungen erstellen lassen, ohne den zeremoniellen Ballast betrieblicher Software-Entwicklung. Wieder nützlich. Wieder keine Magie. Eine erfolgreiche VB-Anwendung hörte irgendwann auf, ein kleiner Helfer zu sein, und wurde zu einem System, von dem Menschen abhingen.

Excel plus VBA tat still und überall dasselbe. Eine Tabelle löste einen lästigen Prozess. Dann noch einen. Dann bekam sie Makros, Schaltflächen, verborgene Blätter, kopierte Formeln, eingefügte Exporte und eine Person in der Finanzabteilung, die „als Einzige versteht, wie das funktioniert“. Jahre später entdeckt das Unternehmen, dass ein geschäftskritischer Prozess auf einer Datei läuft, die niemand gefahrlos ändern kann.

Legacy-VBA mit KI und dem Schweizer-Käse-Modell zeigt denselben Mechanismus. Der schwierige Teil besteht nicht darin, alte Syntax in neue Syntax zu übersetzen. Er besteht darin herauszufinden, was das System tatsächlich tut, zu beweisen, dass der Ersatz das wichtige Verhalten bewahrt, und genug Validierungsschichten einzubauen, damit „fast richtig“ nicht zum geschäftlichen Schaden wird.

KI ist die neueste und mächtigste Variante dieses Musters. Sie senkt die Kosten, softwareförmige Dinge zu erzeugen. Das ist nützlich. Es bedeutet aber auch, dass aus einer schwachen Idee eine funktionierende Demo werden kann, bevor jemand die Fragen gestellt hat, die ein Entwickler mit Erfahrung aus dem Softwarebetrieb in der ersten Stunde stellen würde.

Was passiert, wenn der Anbieter nicht rechtzeitig antwortet?

Wem gehören die Daten, nachdem sich der Prozess geändert hat?

Was wird protokolliert?

Was lässt sich erneut abspielen?

Wie sieht der Weg zurück aus?

Welche Regeln sind Vorgaben, welche Gewohnheit und welche bloße Folklore?

Das Tool stellt diese Fragen nicht hartnäckig genug. Ein erfahrener Praktiker schon.

Dokumentation ist kein Urteilsvermögen

Dokumentation ist der beliebteste Kompromiss, wenn niemand zugeben will, dass im Raum Urteilsvermögen in Softwarefragen fehlt.

Prozess aufschreiben. Ablauf abbilden. Anforderungen dokumentieren. Ausnahmetabelle erstellen. Betriebshandbuch produzieren. Das fühlt sich sicher an, weil Dokumentation sichtbar, prüfbar und politisch neutral ist. Niemand muss das Unbequeme aussprechen: Der dokumentierte Prozess kann bereits voller Widersprüche, verborgener Umgehungslösungen, falscher Anreize und Regeln sein, an die sich tatsächlich niemand hält.

Wer das automatisiert, bekommt ausführbare Verwirrung.

Deshalb enttäuscht reine Konfiguration so oft. Konfiguration ist nicht neutral. Jede Auswahlliste, Zuordnung, jeder Auslöser, jede Bedingung, Berechtigung und Eskalationsregel ist eine Designentscheidung. Dass sie in einem Anbieter-Tool steckt, macht sie nicht weniger zu einer Architekturentscheidung. Es macht die Architektur nur schwerer sichtbar.

Dasselbe gilt für KI-generierte Werkzeuge. Die erste Version kann wie ein Wunder wirken. Ein Formular erscheint. Eine Datenbanktabelle erscheint. Ein Freigabeablauf erscheint. Ein Dashboard erscheint. Alle sind beeindruckt, weil der sichtbare Teil so schnell da war.

Zuverlässige Software besteht jedoch größtenteils aus unsichtbaren Teilen.

Validierung. Tests. Nachvollziehbarkeit. Datenmigration. Fehlerbehandlung. Rollengrenzen. Disziplin bei Releases. Beobachtbarkeit. Änderungshistorie. Betriebliche Verantwortung. Die langweilige Maschinerie, die ein System am Leben hält, wenn der Glanz der Demo verblasst.

Vibe Coding ist keine Software-Entwicklung: Ein Prompt kann Code erzeugen, aber keine Verantwortung übertragen. Wer die Arbeit verantwortet, muss weiterhin wissen, was „gut“ bedeutet, wenn der Happy Path nicht mehr reicht.

Was Erfahrung aus dem Softwarebetrieb bringt

Menschen mit Erfahrung aus dem Softwarebetrieb zeichnen sich nicht dadurch aus, dass sie mehr Tools kennen. Sie sind nützlich, weil sie denselben Fehler schon in verschiedenen Kostümen gesehen haben.

Sie haben erlebt, wie „vorübergehende“ Tabellen zur maßgeblichen Datenquelle wurden. Sie haben gesehen, wie Anbieter-Konfiguration zu nicht testbarer Geschäftslogik heranwuchs. Sie haben Freigabeabläufe debuggt, deren eigentlicher Zweck darin bestand, Verantwortung zu vermeiden. Sie haben Code geerbt, den jemand in dem Glauben geschrieben hatte, Dokumentation werde schon genügen. Sie haben unter Termindruck Software geliefert, etwas kaputt gemacht, es repariert, danach den Test geschrieben und sich die Beule gemerkt.

Diese Erfahrung verändert ihre Fragen.

Sie fragen nicht nur, ob das Tool es kann. Sie fragen, ob die Organisation damit leben kann.

Sie fragen nicht nur, ob der Ablauf dokumentiert ist. Sie fragen, welche Regel zum ersten Streit führt, sobald Geld, Compliance oder Kundenärger im Spiel sind.

Sie fragen nicht nur, ob KI den Code erzeugt hat. Sie fragen, wer ihn lesen, testen, bereitstellen, zurückrollen und erklären kann, wenn die erzeugte Abstraktion in den Betrieb durchsickert.

Sie fragen nicht nur, ob der Anbieter eine Funktion hat. Sie fragen, was passiert, wenn diese Funktion nicht ganz zum echten Prozess des Unternehmens passt. Denn in diesem „nicht ganz“ wächst die teure Umgehungslösung.

Deshalb ist der modische Titel „Forward Deployed Software Engineer“ interessant. Palantir verwendet ihn für Menschen, die direkt in den Teams ihrer Kunden arbeiten und Software für schwierige betriebliche Probleme konfigurieren und erweitern. Der Titel gehört ihnen; der Bedarf ist allgemeiner. Wertvoll ist nicht die Bezeichnung, sondern die Haltung: nah genug am Geschäft, um das echte Problem zu verstehen, und technisch stark genug, um beim Bauen die Folgen für den Produktionsbetrieb mitzudenken.

2026 kann eine solche Person mit KI sehr schnell viel bewegen. Bei vielen internen Tools geht es um Tage, nicht Monate. Aber Geschwindigkeit zählt nur, weil Urteilsvermögen die Arbeit leitet. Ohne dieses Urteilsvermögen erzeugt dieselbe Geschwindigkeit lediglich eine hübschere Variante der alten Excel-Makro-Falle.

Die Runde ist falsch besetzt

In Digitalisierungsrunden sitzen oft viele Menschen mit legitimer Entscheidungsbefugnis – aber niemand mit der Erfahrung, auf die es für dieses Risiko ankommt.

Der Prozessverantwortliche weiß, wie die Arbeit ablaufen soll. Der Anbieter kennt das Produkt. Der Berater weiß, wie das Programm in Bewegung bleibt. Der Projektmanager kennt den Zeitplan. Der Sponsor aus der Geschäftsleitung kennt das Budget und die politische Tragweite.

Alles nützlich.

Noch immer nicht genug.

Es fehlt die Person, die ruhig und früh sagen kann: „Sie bauen ein Software-System. Hier wird das System im Betrieb versagen. Das müssen wir beweisen, bevor jemand davon abhängt. Das ist die kleinste zuverlässige Version, die wir zuerst bauen können. Dieser Teil sollte manuell bleiben, bis wir die Ausnahme verstehen. Dieser Test wird uns ehrlich halten.“

Diese Person wird oft herausgefiltert, weil sie in keine Einkaufskategorie passt. Zu technisch für den Strategieraum. Zu breit aufgestellt für das Stellenprofil. Zu praktisch für den Transformationsworkshop. Zu ehrlich für die Behauptung, Konfiguration sei harmlos.

Also kauft die Organisation Tools, schreibt Dokumentation, konfiguriert Abläufe, feiert das Pilotprojekt und stellt später fest, dass sie Software ohne die Gewohnheiten geschaffen hat, die Software am Leben halten.

Die Lehre lautet nicht, Automatisierungs-Tools abzulehnen. Nutzen Sie sie. Die Lehre lautet, Tools nicht länger mit Fähigkeit zu verwechseln.

Der Management-Test

Stellen Sie vor dem nächsten Digitalisierungsprojekt eine unbequeme Frage:

Wer im Raum hat nach der Demo Verantwortung für Software getragen?

Nicht, wer eine Plattform ausgewählt hat. Nicht, wer einen Anbieter gesteuert hat. Nicht, wer Anforderungen geschrieben hat. Nicht, wer einen Workshop moderiert hat.

Wer hat mit dem System gelebt, nachdem die Benutzer die Grenzfälle gefunden hatten?

Wer hat erlebt, wie eine kleine Automatisierung zu kritischer Infrastruktur wurde?

Wer hat sich mit einer fehlgeschlagenen Bereitstellung, einer schlechten Migration, einem Sicherheitsfehler, einer kaputten Integration, einer Support-Eskalation oder einer Geschäftsregel befasst, die sich in Produktion als falsch erwies?

Wenn diese Person nicht im Raum sitzt, fliegt das Projekt blind – nur mit schöneren Unterlagen.

KI macht das dringlicher, nicht weniger wichtig. Die erste funktionierende Version kann erscheinen, bevor die Führung überhaupt den ersten Termin des Lenkungsausschusses gefunden hat. Das ist nur dann ein Vorteil, wenn jemand mit Erfahrung aus dem Softwarebetrieb nah genug dran ist, um sie mitzugestalten. Andernfalls bekommt die Organisation das alte Versprechen noch einmal: Software-Entwicklung, leicht gemacht für Menschen, die noch nicht gelernt haben, warum sie schwierig wurde.

Es fehlt nicht noch ein Tool-Experte.

Es fehlt nicht noch ein Dokumentationsverantwortlicher.

Es fehlt nicht noch ein Framework-Berater.

Es fehlt jemand, der bauen, prüfen, vereinfachen und Nein sagen kann, bevor das Unternehmen aus einer Demo eine Abhängigkeit macht.

Dort entsteht echter Wert.