Software als Einzelstück: Warum Prozesswissen jetzt zählt

KI verändert die Ökonomie maßgeschneiderter Software. Für den Mittelstand entsteht eine neue Möglichkeit: Menschen, die einen Ablauf wirklich verstehen, können seine Digitalisierung stärker selbst gestalten. Damit verschiebt sich auch die Aufgabe der Entwickler.

Kürzlich zeigte mir ein Freund ein altes Konsolenspiel aus seiner Kindheit. Er hatte mithilfe von KI-Werkzeugen versucht, aus dem ausführbaren Programm wieder eine bearbeitbare Grundlage zu gewinnen. Nach einigen Wochen lief eine Version, die er vorführen konnte. Was mich dabei beschäftigte, war weniger das Spiel selbst als die Frage dahinter: Was wird möglich, wenn der Weg vom fertigen Produkt zurück zu einem verständlichen Bauplan deutlich kürzer wird?

Das ist eine persönliche Beobachtung, kein Leistungsvergleich. Sie sagt nicht, dass sich jedes Programm in Wochen rekonstruieren lässt, und schon gar nicht, dass solche Vorhaben rechtlich unproblematisch wären. Aber die Szene steht für eine Veränderung, die uns inzwischen auch in der Beratung begegnet.

Unternehmen kommen immer häufiger mit Fragen der Befähigung auf uns zu: Wie können Produktverantwortliche, Fachabteilungen und Entwickler gemeinsam mit KI bessere Software bauen? Wie bekommen wir dafür einen belastbaren Arbeitsprozess hin? Der Auftrag fängt häufiger beim eigenen Team und seiner Arbeitsweise an.

Für uns verdichtet sich daraus eine These: Bei überschaubaren internen Werkzeugen kann es einfacher werden, einem Prozesskenner die KI-gestützte Umsetzung beizubringen, als sein gesamtes Erfahrungswissen zunächst an ein externes Entwicklungsteam zu übertragen.

Inhalt dieses Artikels

1. Warum ein Werkzeug sich nicht für tausend Kunden rechnen muss
2. Zugänglichere Baupläne, anspruchsvoller Betrieb
3. Wer den Prozess kennt, gehört an den Bautisch
4. Prozesswissen wird zum Vermögen – wenn es überprüfbar wird
5. Erst Verantwortung macht aus einem Prototyp ein Arbeitsmittel
6. Günstigerer Code heißt nicht automatisch kleinere Budgets
7. Wie Sie den Wandel im eigenen Betrieb prüfen

Warum ein Werkzeug sich nicht für tausend Kunden rechnen muss

Standardsoftware folgt einer einfachen, nachvollziehbaren Logik: Hohe Entwicklungskosten werden auf viele Kunden verteilt. Damit das aufgeht, muss das Produkt genügend Gemeinsamkeiten zwischen diesen Kunden finden. Der einzelne Betrieb passt seine Arbeit an die vorgesehenen Möglichkeiten an – oder bezahlt zusätzliche Anpassungen.

Diese Logik hat viel Gutes hervorgebracht. Buchhaltung, Kommunikation und zahlreiche Verwaltungsaufgaben profitieren davon, dass bewährte Lösungen breit verfügbar sind. Kein Unternehmen gewinnt automatisch einen Wettbewerbsvorteil, nur weil es jedes Adressbuch selbst entwickelt.

Schwierig wird es dort, wo der eigene Ablauf von der vorgesehenen Norm abweicht. Eine Freigabe hängt an einer besonderen Kundenvereinbarung. Ein Auftrag läuft durch drei Systeme, deren Daten nicht zusammenpassen. Eine erfahrene Mitarbeiterin weiß, warum eine scheinbar vollständige Akte trotzdem zurückgehalten werden muss. Solche Unterschiede landen häufig in Tabellen, E-Mails und handschriftlichen Ergänzungen.

Lange war der Aufwand für eine eigene Lösung schwer zu rechtfertigen. Ein Werkzeug für acht Menschen musste dieselben grundlegenden Entwicklungshürden nehmen wie ein Produkt für mehrere tausend Nutzer. Daraus entstand eine merkwürdige Situation: Ein wichtiger betrieblicher Vorgang blieb mühsam, weil sein Markt zu klein war.

KI-gestützte Entwicklung kann diese Rechnung verändern. Wenn sich erste Oberflächen, Datenmodelle, Schnittstellen und Tests mit weniger Aufwand erstellen lassen, rücken kleinere Vorhaben in Reichweite. Eine Anwendung darf dann genau einem Unternehmen dienen. Sie muss sich nicht zu einem allgemeinen Softwareprodukt erweitern lassen, damit ihre Entstehung sich gelohnt hat.

Das meinen wir mit Software als Einzelstück, im Englischen auch als bespoke oder one-of-one software bezeichnet: ein Arbeitsmittel, dessen Form aus einem konkreten betrieblichen Bedarf entsteht. Einzelstück heißt nicht, alle technischen Bausteine neu zu erfinden. Standardkomponenten können gerade dafür sorgen, dass nur die wirklich besondere Geschäftslogik individuell gebaut werden muss.

Die entscheidende Rechnung bleibt betriebswirtschaftlich: Was kostet der heutige Ablauf, Fehler, Wartezeiten und Nacharbeit eingerechnet? Was kostet die passende Lösung über ihre gesamte Nutzungsdauer? Günstiger erzeugter Code ist ein Teil dieser Rechnung. Der Nutzen entsteht erst im Alltag.

Zugänglichere Baupläne, anspruchsvoller Betrieb

Öffentliche Projekte zeigen, wie weit Entwickler mit den neuen Werkzeugen kommen. Ein Beispiel ist PhotoCraft, ein in Rust geschriebenes, quelloffenes Bildbearbeitungsprojekt. Solche Vorhaben sind interessant, weil sie sichtbar machen, dass die Umsetzung umfangreicher Softwarekonzepte für weitere Akteure erreichbar wird.

Die Einordnung ist dabei entscheidend. PhotoCraft bezeichnet sich selbst als frühe Alpha und ausdrücklich noch nicht als Photoshop-Ersatz für den täglichen professionellen Einsatz. Das Projekt benennt offen Lücken bei Werkzeugen, Typografie, professionellen Abläufen und Kompatibilität. Die Erzählung von einer vollständig nachgebauten Adobe-Suite geht deutlich weiter als dieser Nachweis.

Zwischen einer beeindruckenden Implementierung und einem verlässlichen Arbeitsmittel liegt viel: ungewöhnliche Dateien, lang gewachsene Integrationen, Barrierefreiheit, Support, Updates und die Frage, wer einen Fehler am nächsten Morgen behebt. Ein Geschäftskunde kauft diese Verlässlichkeit mit. Er bezahlt selten nur dafür, dass ein Menüpunkt existiert.

Was sich plausibel verändert, ist das relative Gewicht der Schutzwälle. Allein darauf zu setzen, dass Außenstehende die eigene Implementierung nur schwer nachvollziehen oder nachbauen können, dürfte für manche Anbieter künftig weniger tragen. Vertrauen, Integration, Datenqualität, Arbeitsabläufe und langfristig verlässliche Leistung gewinnen daneben an Bedeutung. Wie stark, unterscheidet sich von Produkt zu Produkt.

Warum eine andere Programmiersprache kein rechtlicher Neustart ist

Funktionalität und geschützter Programmcode sind rechtlich zu trennen. Der Europäische Gerichtshof hat im Fall SAS Institute unter anderem die Funktionalität eines Programms und seine Programmiersprache als solche von der geschützten Ausdrucksform abgegrenzt. Daraus folgt keine allgemeine Erlaubnis, fremden Quell- oder Objektcode zu kopieren.

Die EU-Softwarerichtlinie behandelt auch Übersetzungen und Umarbeitungen grundsätzlich als zustimmungspflichtige Handlungen; Ausnahmen haben konkrete Voraussetzungen. Eine Funktion unabhängig neu zu implementieren ist deshalb etwas anderes, als übernommenen Code nach Rust zu übertragen. Für ein konkretes Vorhaben müssen Rechte, Herkunft und Vorgehen geprüft werden. Die Sprache allein löst diese Fragen nicht.

Für den Mittelstand liegt die attraktivere Chance ohnehin häufig im eigenen Bedarf: eine Lösung für einen Ablauf zu bauen, den man selbst verantwortet und versteht.

Wer den Prozess kennt, gehört an den Bautisch

Ein erheblicher Reibungsverlust kann entstehen, bevor überhaupt eine erste produktive Version existiert. Menschen aus dem Fachbereich erklären ihre Arbeit. Ein Projektteam übersetzt das Gesagte in Anforderungen. Entwickler übersetzen diese Anforderungen in ein System. Erst bei der Benutzung zeigt sich, welche Regeln nie ausgesprochen wurden.

Das ist selten mangelnde Sorgfalt. Erfahrene Menschen handeln mit viel implizitem Wissen. Sie erkennen, welcher Lieferant zuverlässig nachliefert, welche Abweichung eine Rückfrage verlangt und wann eine formell korrekte Eingabe praktisch falsch ist. Wer täglich mit einem Vorgang arbeitet, nimmt manche Entscheidung gar nicht mehr als besondere Regel wahr.

Kann diese Person einen kleinen Prototyp direkt mitgestalten, verkürzt sich die Rückmeldung. Eine Maske wird ausprobiert. Ein Sonderfall fällt auf. Eine Regel wird konkretisiert. Die nächste Fassung zeigt, ob die Erklärung tatsächlich trägt. Das Fachwissen bleibt näher an seiner Umsetzung.

Die veränderten Beratungsanfragen stützen diese Einschätzung. Ob sie im einzelnen Betrieb trägt, muss sich am konkreten Vorhaben zeigen.

Ein Fachverantwortlicher muss dafür nicht plötzlich eine verteilte Systemarchitektur entwerfen können. Er sollte aber verstehen, was eine Anwendung lesen und verändern darf, wie ihre Ergebnisse geprüft werden und wann technische Unterstützung nötig ist. Umgekehrt braucht ein Entwickler nicht jede Feinheit des Geschäfts von Anfang an zu kennen, wenn er eng genug mit dem Fachverantwortlichen zusammenarbeitet.

So verändert sich die Zusammenarbeit. Fachleute liefern mehr als Anforderungen. Entwickler leisten mehr als die Übersetzung eines Pflichtenhefts: Sie entwerfen die tragfähige technische Umgebung, helfen bei schwierigen Entscheidungen und sichern die Übergänge zum laufenden Betrieb. Die Nähe zwischen beiden Aufgaben wird wertvoller.

Was die Produktivitätsstudien wirklich hergeben

Auch bei professionellen Entwicklern fällt der Effekt von KI nicht einheitlich aus. Eine Studie mit drei betrieblichen Experimenten und 4.867 Entwicklern schätzt im zusammengefassten Modell rund 26 Prozent mehr wöchentliche Pull Requests durch die Nutzung früherer Copilot-Versionen. Die Einzelversuche waren statistisch unpräzise. Gemessen wurde eine Outputgröße – nicht der Gesamtwert fertiger Produkte oder ihre langfristige Wartbarkeit.

METR fand in einer Untersuchung aus dem ersten Halbjahr 2025 mit erfahrenen Open-Source-Entwicklern und den damaligen Werkzeugen 19 Prozent mehr Bearbeitungszeit. Im Update vom Februar 2026 beschreibt das Forschungsteam zugleich, warum sich aus seinen neueren Daten keine verlässliche aktuelle Effektgröße ableiten lässt. Werkzeuge, Aufgaben, Teilnehmende und Arbeitsweisen verändern sich laufend.

Beides mahnt zur Nüchternheit. Aus solchen Befunden folgt weder, dass KI generell bremst, noch ein universeller Beschleunigungsfaktor. Sie belegen außerdem keinen direkten Vergleich zwischen Prozesskennern und externen Entwicklerteams. Genau deshalb sollte ein Unternehmen seinen eigenen Ablauf messen, statt eine Zahl aus einer anderen Umgebung zum Business Case zu erklären.

Prozesswissen wird zum Vermögen – wenn es überprüfbar wird

Wenn die erste Umsetzung leichter wird, fällt stärker auf, was sich nicht einfach erzeugen lässt: das Wissen darüber, welche Lösung in einem bestimmten Unternehmen richtig wäre. Aber auch hier lohnt eine Unterscheidung. Ein gewachsener Prozess ist nicht allein deshalb gut, weil er alt und schwer erklärbar ist.

Manche Besonderheit schafft einen echten Vorteil. Eine andere gleicht nur eine Schwäche der bisherigen Software aus. Wieder eine andere existiert, weil niemand mehr weiß, warum eine Regel eingeführt wurde. Wer alle drei Varianten ungeprüft automatisiert, baut die Vergangenheit besonders effizient nach.

Gute Prozessarbeit fragt deshalb zuerst: Welches Ergebnis brauchen wir? Welche Entscheidungen tragen dazu bei? Welche Regeln sind notwendig, welche nur Gewohnheit? Erst dann bekommt die Umsetzung eine Richtung. Das kann zu einer eigenen Anwendung führen – oder zeigen, dass eine vorhandene Standardfunktion ausreicht.

Ein fiktives Beispiel: In einem Fertigungsbetrieb werden Lieferpapiere erfasst, Bestellungen zugeordnet und Abweichungen geklärt. Eine erste Anwendung kann Dokumente auslesen und passende Aufträge vorschlagen. Der eigentliche Wert zeigt sich aber bei Teilmengen, unleserlichen Belegen, Retouren und Fällen, in denen eine Bestellnummer zwar passt, der Inhalt jedoch nicht.

Die erfahrene Mitarbeiterin kennt diese Fälle. Gemeinsam mit einem technischen Partner kann sie daraus eine prüfbare Sammlung machen: So sieht ein normaler Vorgang aus. Hier muss die Anwendung nachfragen. Dort darf sie einen Vorschlag machen, aber nichts verbuchen. Dieser Fall geht an eine bestimmte Person.

Damit wird Erfahrungswissen zur Grundlage für Entwicklung und Abnahme. Eine kleine Menge guter Originalfälle kann hilfreicher sein als ein dickes Pflichtenheft voller allgemeiner Wünsche. Wichtig sind dabei geeignete Daten und geklärte Zugriffe; sensible Dokumente gehören nicht unbedacht in beliebige Werkzeuge.

Auch die Zusammenarbeit mit externen Partnern lässt sich so präziser gestalten. Es braucht klare Vereinbarungen zu Vertraulichkeit, Nutzungsrechten, Quellcode, Datenexport und Betrieb. Prozesswissen bleibt nicht dadurch geschützt, dass man jede Zusammenarbeit vermeidet. Entscheidend ist, welche Informationen und Rechte für einen definierten Zweck geteilt werden.

Erst Verantwortung macht aus einem Prototyp ein Arbeitsmittel

Eine Vorführung ist ein Versprechen: Dieser Weg könnte funktionieren. Der produktive Einsatz verlangt zusätzlich eine Antwort darauf, was bei Abweichungen passiert. Ein Dokument wird doppelt hochgeladen. Ein Dienst ist nicht erreichbar. Eine Berechtigung ändert sich. Zwei Personen bearbeiten denselben Vorgang.

Solche Fälle sind kein nachträglicher Feinschliff. Sie gehören zur Funktion. Gerade kleine interne Werkzeuge greifen oft an empfindlichen Stellen in den Alltag ein – schließlich sollen sie genau die Lücke schließen, die bisher eine erfahrene Person kontrolliert hat.

Für einen überschaubaren Einstieg reicht häufig eine kleine, klar besetzte Zusammenarbeit: Jemand verantwortet den fachlichen Ablauf, jemand die technische Tragfähigkeit. Je nach Risiko kommen Datenschutz, Sicherheit oder andere zuständige Stellen hinzu. Nicht jedes Vorhaben braucht ein großes Team. Jedes braucht Menschen, die Entscheidungen und Folgen übernehmen.

Zu einer brauchbaren Lösung gehören deshalb auch Dinge, die eine Demo nicht spektakulärer machen: nachvollziehbare Änderungen, passende Zugriffsrechte, eine Sicherung, ein Rückweg bei Fehlern und ein benannter Ansprechpartner. Ebenso wichtig ist die Entscheidung, wie lange das Werkzeug gepflegt werden soll und wann es wieder abgeschaltet wird.

Software als Einzelstück darf in ihrer Funktion individuell sein. Für Betrieb und Qualität sollte sie möglichst auf wiederverwendbaren Standards aufbauen. Ein Unternehmen, das zehn interne Werkzeuge entwickelt, braucht nicht zehn völlig verschiedene Verfahren für Anmeldung, Sicherung und Wartung.

Das ist zugleich die Grenze der Erzählung von kostenloser Software. Manche Programmierarbeit wird günstiger. Die Verantwortung für ein verlässliches Ergebnis verschwindet dadurch nicht. Sie verteilt sich neu – und gehört von Anfang an in die Rechnung.

Günstigerer Code heißt nicht automatisch kleinere Budgets

In der Diskussion fehlt oft die Zeitachse. Wenn ein Werkzeug eine bestimmte Aufgabe billiger macht, können wir die Ersparnis behalten. Wir können aber auch Aufgaben angehen, die bisher zu aufwendig waren. Dann steigt die Leistungsfähigkeit, während das Budget ähnlich hoch bleibt oder sogar wächst.

Ein Betrieb beginnt vielleicht mit einer einfacheren Belegerfassung. Sobald diese funktioniert, werden Zuordnung, Rückfragen, Freigaben und Auswertung interessant. Aus einem kleinen Hilfsmittel entsteht ein besser verbundener Ablauf. Die erste Verbesserung hat zusätzliche Möglichkeiten sichtbar gemacht.

Ähnliche Muster kennt die Büroarbeit schon. Textverarbeitung erleichterte das Überarbeiten von Dokumenten; zugleich stiegen die Erwartungen an Gestaltung, Varianten, Geschwindigkeit und Verfügbarkeit. Neue Werkzeuge nutzen wir selten dauerhaft nur dafür, das alte Ergebnis etwas billiger herzustellen.

In diesem Sinn ist das Jevons-Paradox für KI und Arbeit ein hilfreicher Denkansatz: Sinkende Kosten können zusätzliche Nachfrage auslösen. Für Software heißt das, dass weitere Projekte wirtschaftlich werden können. Daraus folgt weder zwangsläufig mehr Beschäftigung noch die Sicherheit eines bestimmten Berufs oder Geschäftsmodells.

Weniger Arbeitsstunden je Projekt und eine größere Zahl von Projekten können gleichzeitig entstehen. Welche Bewegung überwiegt, hängt unter anderem von Nachfrage, verfügbaren Budgets, Fähigkeiten und den Grenzen der Umsetzung ab. Eine pauschale Zahl für den Entwicklerbedarf wäre hier Scheingenauigkeit.

Für Entwickler eröffnet sich trotzdem eine interessante Perspektive. Wenn einfache Umsetzungsschritte weniger Zeit beanspruchen, können Architektur, schwierige Integrationen, Betrieb und fachliche Zusammenarbeit stärker in den Mittelpunkt rücken. Gleichzeitig verlieren bestimmte Routinetätigkeiten an Wert. Der Übergang kann Möglichkeiten eröffnen – und für einzelne Menschen oder Firmen unbequem sein.

Die unternehmerische Frage lautet deshalb: Welche zusätzliche Fähigkeit wollen wir gewinnen? Wer lediglich immer mehr Anwendungen erzeugt, erzeugt unter Umständen auch immer mehr Pflegeaufwand. Auswahl wird wichtiger, wenn die Zahl der machbaren Vorhaben wächst.

Wie Sie den Wandel im eigenen Betrieb prüfen

Es braucht weder eine pauschale Entscheidung gegen Standardsoftware noch ein Programm zur vollständigen Neuerfindung der IT. Sinnvoll ist ein begrenztes Vorhaben, an dem sich die neue Arbeitsteilung überprüfen lässt.

1. Einen konkreten Reibungspunkt auswählen. Beschreiben Sie einen wiederkehrenden Vorgang mit klar erkennbarem Anfang und Ergebnis. Halten Sie fest, wo heute Wartezeit, Fehler oder Nacharbeit entstehen. Ein Wunsch wie „Wir brauchen mehr KI“ ist dafür zu ungenau.
2. Das Fachwissen an den Tisch holen. Beteiligen Sie die Person, die den Ablauf täglich kennt, und einen technischen Partner. Sammeln Sie typische Fälle und wichtige Ausnahmen. Klären Sie dabei auch, welche Besonderheiten wirklich erhalten werden sollen.
3. Kaufen, anpassen und bauen vergleichen. Prüfen Sie vorhandene Funktionen und geeignete Standardprodukte, bevor Sie individuell entwickeln. Rechnen Sie Einführung, Schnittstellen, Datenpflege, Betrieb und einen möglichen späteren Wechsel mit ein.
4. Einen überprüfbaren Prototyp begrenzen. Legen Sie vorab fest, woran ein guter Durchlauf zu erkennen ist. Vergleichen Sie Bearbeitungszeit, Korrekturen und fachliche Richtigkeit mit dem heutigen Vorgehen. Wo Folgen relevant sind, bleibt die Entscheidung zunächst beim Menschen.
5. Den Betrieb vor der Ausweitung klären. Wer gibt Änderungen frei? Wer reagiert auf Fehler? Wie werden Daten gesichert und Rechte entzogen? Erst wenn diese Fragen beantwortet sind, wird aus dem Versuch ein dauerhaftes Arbeitsmittel.

Ein guter Versuch darf auch mit der Entscheidung enden, etwas nicht selbst zu bauen. Vielleicht deckt ein vorhandenes Produkt den Bedarf ausreichend ab. Vielleicht ist der Prozess noch zu unklar. Vielleicht lohnt die individuelle Lösung gerade deshalb, weil ihr Nutzen in wenigen besonderen Regeln liegt. Jede dieser Antworten ist wertvoller als ein weiterer unbetreuter Prototyp.

Die eigentliche Chance dieser Entwicklung liegt für uns in einer größeren Nähe zwischen Wissen und Gestaltung. Menschen, die täglich sehen, wo Arbeit unnötig kompliziert wird, können mehr Einfluss auf ihre Werkzeuge gewinnen. Technische Fachleute können ihnen dabei helfen, aus einer guten Idee ein verlässliches System zu machen.

Wir nehmen die neuen Möglichkeiten ernst und prüfen sie an der Arbeit, die tatsächlich besser werden soll. Software als Einzelstück wird dann interessant, wenn sie zu einem Prozess passt, Menschen entlastet und sich im Betrieb bewährt.

Einen passenden Prozess gemeinsam prüfen

Im 15-Minuten-KI-Sprint-Check klären wir, welcher konkrete Ablauf sich für einen ersten Versuch eignet und ob eine vorhandene Lösung, eine Anpassung oder ein eigenes Werkzeug sinnvoll ist.

15-Minuten-KI-Sprint-Check vereinbaren

Weiterlesen

• Das goldene Zeitalter der Branchensoftware
• Es ist nicht vorbei: Jevons-Paradox, KI und Arbeit
• Agentische Systeme und Prozessoptimierung