Allgemein Archive | Digifinity

KI-Agents in der Softwareentwicklung: worauf es bei Grenzen und Aufträgen ankommt

Paul Engelhardt — Tue, 27 Oct 2026 03:59:41 +0000

KI-Agents in der Softwareentwicklung: worauf es bei Grenzen und Aufträgen ankommt

KI-Agents können heute große Teile einer Entwicklungsaufgabe selbstständig erledigen. Sie lesen Code, ändern Dateien, führen Befehle aus und prüfen ihre eigenen Ergebnisse. Wie verlässlich das ist, hängt nicht nur vom Modell ab. Es hängt auch davon ab, wie der Agent aufgestellt ist: was er darf, wie sein Auftrag lautet und was als Ergebnis zählt.

Eine Regel im Prompt ist keine Grenze

„Ändere keine Dateien außerhalb dieses Ordners.“ „Greif nicht auf die Produktivdatenbank zu.“ „Lösche nichts.“ Solche Sätze stehen in vielen Anweisungen an Agents. Meistens hält sich das Modell daran. Aber eben nur meistens.

Eine Anweisung ist eine Bitte an ein Modell, das Wahrscheinlichkeiten folgt. Sie kann in einem langen Kontext untergehen, mit einer anderen Anweisung kollidieren oder von Text überlagert werden, der in einer gelesenen Datei steht und selbst wie eine Anweisung klingt.

Was auf keinen Fall passieren darf, kann im Prompt stehen. Es muss aber zusätzlich in der Umgebung durchgesetzt werden. Ein Agent, der nur analysieren soll, bekommt nur Lesezugriff. Lässt seine Umgebung keinen schreibenden Zugriff auf das Produktivsystem zu, kann er es nicht verändern, egal was in seinem Kontext steht. Freigegebene Werkzeuge, eine abgeschottete Umgebung und Prüfungen, die bestimmte Befehle vor der Ausführung blockieren, sind harte Grenzen. Der Prompt beschreibt, wie der Agent arbeiten soll. Was er nicht tun kann, regeln Rechte und Werkzeuge.

Ein Auftrag erzeugt Ergebnisse

Wer einem Agent sagt, er soll Probleme im Code finden, bekommt Probleme. Das ist gut, solange es welche gibt.

Ist der Code in Ordnung, findet der Agent unter Umständen trotzdem welche. Aus einer Stilfrage wird ein Risiko, aus einer Vermutung ein Befund. Manchmal wird ein Problem beschrieben, das so gar nicht existiert. Der Auftrag lautete ja: Finde Probleme.

Dagegen helfen ausdrücklich erlaubte Ausgänge. Ein Agent für Code-Reviews darf mit „keine Befunde“ zurückkommen. Einer für die Fehlersuche darf „kein Defekt“ oder „nicht eindeutig klärbar“ melden, und er ändert keinen Code, nur weil ein Fehler gemeldet wurde. Dazu kommt eine Belegpflicht: Was als Problem gemeldet wird, muss konkret belegt sein, mit der Stelle im Code und einer nachvollziehbaren Begründung. Was unsicher ist, wird als unsicher gekennzeichnet.

Ohne solche Ausgänge drängt schon der Auftrag dazu, irgendetwas zu liefern.

Eine Rolle pro Agent

Ein Agent, der alles darf, ist schwer zu kontrollieren. Klarer wird es mit getrennten Rollen: einer analysiert, einer plant, einer setzt um, einer prüft. Jede Rolle bekommt nur die Rechte, die sie braucht.

Besonders wichtig ist das beim Prüfen. Ein Agent, der Tests schreibt und anschließend bewertet, ob die Tests gut sind, prüft sich selbst. Das ist in der Softwareentwicklung mit Menschen nicht anders: Ein Review ist mehr wert, wenn es nicht vom Autor stammt.

Übergaben sind die Bruchstellen

Mit Agents wird es leicht, ganze Arbeitsabläufe zu verketten. Ein Agent findet eine Auffälligkeit, der nächste behebt sie, ein dritter prüft den Fix. Jeder Schritt ist sauber erledigt. Nur hat niemand gefragt, ob die Stelle überhaupt behoben werden sollte. Vielleicht ist sie bewusst so gebaut. Vielleicht spielt sie keine Rolle. Vielleicht kostet der Fix mehr als das Problem.

In einem Projekt entscheidet das normalerweise jemand, der den Kontext kennt, oft in wenigen Sekunden. In einer automatischen Kette kann dieser Moment wegfallen. Aus dem Befund wird direkt eine Aufgabe.

Dabei geht an einer Übergabe nicht unbedingt Information verloren. Aber ihre Gewichtung kann sich verschieben. Was ein Hinweis war, wird beim nächsten Agent zur Vorgabe. Was als Möglichkeit gemeint war, wird behandelt wie ein Beschluss.

Das gilt auch für Texte, die ein Agent liest. Ein Bericht, eine README oder ein früheres Ergebnis ist Kontext, kein Auftrag. Steht darin eine Empfehlung, ist sie noch keine Entscheidung.

Für klar abgegrenzte, wiederholbare Abläufe kann eine Kette sinnvoll sein. Bei Entwicklungsarbeit, die viel Kontext braucht, ist es verlässlicher, wenn ein Mensch an den Übergaben entscheidet, ob und wie es weitergeht.

Was ein Agent nicht sehen kann

Ein Agent sieht den Code und das, was in seinem Kontext steht. Er sieht nicht, warum eine Stelle vor Jahren so gebaut wurde, welcher Kunde auf einen Sonderfall angewiesen ist oder welche Absprache zwischen zwei Abteilungen nirgends dokumentiert ist.

Von außen sieht manches deshalb falsch aus, was einen guten Grund hat. Die Befunde eines Agents sind darum ein Ausgangspunkt. Bewerten muss sie jemand, der den Zusammenhang kennt, und die Verantwortung für das Ergebnis bleibt bei ihm.

Wie ich Rollen und Übergaben konkret strukturiere, zeigt mein öffentliches Toolkit für Claude Code.

Der Beitrag KI-Agents in der Softwareentwicklung: worauf es bei Grenzen und Aufträgen ankommt erschien zuerst auf Digifinity.

Wie groß muss eine neue Anwendung gebaut werden?

Paul Engelhardt — Tue, 27 Oct 2026 03:58:57 +0000

Wie groß muss eine neue Anwendung gebaut werden?

Wer eine neue Anwendung entwickeln lässt, bekommt früher oder später Vorschläge wie diese:

„Wir bauen das gleich skalierbar.“
„Am besten teilen wir das in einzelne Services auf.“
„Das neue Framework bringt das doch sowieso schon mit.“

Das klingt nach Weitsicht und sauberer Architektur. Für jemanden, der nicht selbst entwickelt, ist es aber schwer zu beurteilen. Ist das nötig? Oder wird hier mehr gebaut, als die Aufgabe verlangt?

Wann Vorausdenken richtig ist

Manche Dinge sollten von Anfang an stimmen: wie die Daten aufgebaut sind, wer worauf zugreifen darf, wie sich die Anwendung sichern und wiederherstellen lässt. Das später zu ändern, ist teuer.

Auch Wachstum kann ein guter Grund sein, größer zu bauen. Soll die Anwendung absehbar an allen Standorten laufen oder hat ein großer Kunde mit deutlich mehr Aufträgen schon unterschrieben, gehört das in die Planung. Entscheidend ist, dass das Wachstum konkret ist und nicht nur denkbar.

Warum die Technik oft vor der Begründung feststeht

Viele technische Entscheidungen stehen fest, bevor die Begründung existiert. Das hat selten mit Schlamperei zu tun. Die Gründe sind oft andere als die, die man laut ausspricht: Eine Technologie reizt. Man will so etwas endlich einmal bauen. Es wird überall als der richtige Weg dargestellt.

Die fachliche Begründung kommt danach, und sie klingt gut. Damit einzelne Teile unabhängig wachsen können. Damit man später flexibler ist. Damit nicht alles ausfällt, wenn ein Teil Probleme macht. Das können berechtigte Ziele sein. Nur beantwortet keiner dieser Sätze die eigentliche Frage: Welches konkrete Problem oder welche absehbare Anforderung löst das?

Ich nehme mich davon nicht aus. Ich habe selbst schon Lösungen gebaut und mir die Begründung erst hinterher zurechtgelegt.

Was zu viel Architektur kostet

Eine Anwendung, die für eine Größe gebaut ist, die sie nie erreicht, ist nicht nur etwas teurer in der Entwicklung. Mehr Teile bedeuten mehr Stellen, an denen eine Änderung abgestimmt, ausgeliefert und auf Nebenwirkungen geprüft werden muss. Gut gebaut lässt sich das beherrschen. Der Aufwand ist aber da, und er lohnt sich nur, wenn die Aufteilung tatsächlich etwas bringt.

Dazu kommt der Betrieb. Mehr Bestandteile heißt mehr, was überwacht, aktualisiert und verstanden werden muss. In einem Unternehmen ohne große eigene IT-Abteilung ist das eine echte Last. Und sie bleibt, auch wenn der Entwickler, der es so gebaut hat, längst weitergezogen ist.

Fragen, die Sie stellen können

Sie müssen eine Architektur nicht selbst beurteilen können, um gezielt nachzufragen:

Welches konkrete Problem oder welche absehbare Anforderung löst dieser Ansatz?
Woran würden wir merken, dass wir ihn brauchen?
Was spräche gegen den einfacheren Weg?
Was würde es kosten, das später nachzurüsten, wenn es tatsächlich nötig wird?
Wer betreibt das, wenn das Projekt abgeschlossen ist?

Gute Antworten darauf sind konkret. Bleiben sie allgemein, etwa bei „zukunftssicher“ oder „flexibler“, lohnt sich eine Nachfrage.

Erst ankommen, dann ausbauen

Einfach bauen heißt nicht kurzsichtig bauen. Eine Anwendung kann klein starten und trotzdem so aufgebaut sein, dass sie später wachsen kann: mit einer klaren Struktur, sauber getrennten Zuständigkeiten im Code und ohne Abkürzungen, die einen Ausbau verbauen. Wächst die Anforderung tatsächlich, wird dort ausgebaut, wo es eng wird.

Skalierbarkeit ist dann eine Anforderung, die aus der Realität kommt, und kein Ziel an sich.

Bei einer neuen Anwendung kläre ich zuerst, was sie heute leisten muss und was absehbar dazukommt. Danach richtet sich, wie groß gebaut wird: nicht größer als nötig, nicht kurzfristiger gedacht als sinnvoll. Mehr dazu unter Interne Tools und neue Anwendungen.

Der Beitrag Wie groß muss eine neue Anwendung gebaut werden? erschien zuerst auf Digifinity.

Wenn die Software langsam wird: erst die Arbeit prüfen, dann die Hardware

Paul Engelhardt — Tue, 27 Oct 2026 03:57:52 +0000

Wenn die Software langsam wird: erst die Arbeit prüfen, dann die Hardware

„Das System ist langsam geworden.“

Seiten laden länger, ein Bericht braucht Minuten, beim Speichern dreht sich das Symbol. Der erste Gedanke ist meistens derselbe: Es muss am Server liegen. Oder an der Datenbank. Irgendwo muss mehr Leistung her.

Manchmal stimmt das. Häufig liegt das Problem aber darin, wie das System arbeitet. Dann kauft mehr Hardware nur Zeit.

Wann mehr Leistung die richtige Antwort ist

Mehr Leistung ist nicht falsch. Wenn deutlich mehr Menschen mit dem System arbeiten als früher, wenn die Zahl der Aufträge gewachsen ist oder der Server schlicht in die Jahre gekommen ist, kann ein Ausbau die schnellste und günstigste Lösung sein. Bei gemieteten Servern ist das oft schnell erledigt.

Das gilt vor allem, wenn das System die richtige Arbeit macht und sie vernünftig erledigt. Dann wächst der Bedarf mit der Nutzung, und mehr Leistung deckt ihn. Aber auch sonst kann ein Ausbau sinnvoll sein: als schnelle Entlastung, während die eigentliche Ursache behoben wird, oder wenn eine Optimierung deutlich mehr kosten würde als der größere Server.

Wenn das System zu viel arbeitet

Häufig wird ein System langsam, weil es mehr arbeitet als nötig. Typische Ursachen:

Die Anwendung fragt zehn Dinge einzeln bei der Datenbank ab, wo eine Abfrage gereicht hätte. Bei zwanzig Datensätzen merkt das niemand, bei zwanzigtausend schon.
Die Datenbank durchsucht große Tabellen jedes Mal komplett, weil ein passender Index fehlt. Solange die Tabellen klein waren, fiel das nicht auf.
Ergebnisse werden bei jedem Aufruf neu berechnet, obwohl sie sich nur einmal am Tag ändern.
Im Hintergrund laufen Aufgaben, die fachlich niemand mehr braucht, etwa ein Abgleich mit einem System, das längst abgelöst ist.
Der Prozess ist falsch geschnitten. Ein Bericht wird für jeden Nutzer live erzeugt, obwohl ein täglicher Stand reichen würde.

Vieles davon war beim Bau der Anwendung kein Fehler. Es wird erst zum Problem, wenn Daten und Nutzung wachsen.

Wann mehr Hardware das Problem nur verschiebt

Arbeitet ein System ineffizient, wächst sein Aufwand oft schneller als die Datenmenge. Ein doppelt so starker Server bringt dann eine Weile Ruhe, bis die Daten weiter gewachsen sind. Danach ist das Problem wieder da, und jetzt kostet es jeden Monat mehr.

Das eigentliche Problem bleibt. Es wird nur teurer versteckt.

Welcher Weg sich rechnet, hängt davon ab, was beides kostet: zusätzliche Leistung auf Dauer und eine gezielte Optimierung einmalig. Und davon, wie lange jede Lösung voraussichtlich trägt.

Woran man erkennt, wo die Zeit verloren geht

Bevor Geld fließt, lohnt sich ein genauerer Blick. Ein paar Fragen kann jeder im Betrieb beantworten:

Ist alles langsam oder nur bestimmte Aktionen?
Seit wann? Nach einem Update, mit wachsenden Datenmengen, schleichend?
Zu bestimmten Tageszeiten, etwa wenn viele gleichzeitig arbeiten oder ein Abgleich läuft?
Wird es mit jeder Woche ein Stück schlimmer?

Die Antworten grenzen die Ursache bereits ein. Danach lässt sich technisch messen, wo die Zeit tatsächlich hängt: in der Datenbank, in der Anwendung selbst, bei einem angebundenen Dienst oder im Netz. Messen ist dabei der wichtigste Schritt. Wer rät, optimiert schnell an der falschen Stelle.

Die unbequeme Frage

Bevor man ein System schneller macht, lohnt sich eine Frage, die über Technik hinausgeht: Macht es überhaupt noch die richtige Arbeit?

Berichte, die niemand mehr liest. Daten, die für einen Prozess aufbereitet werden, den es so nicht mehr gibt. Prüfungen, die einmal für einen Sonderfall eingebaut wurden, der längst erledigt ist. Was wegfallen kann, muss man nicht schneller machen.

Wird Ihr System langsamer, untersuche ich, wo die Zeit verloren geht und welche Maßnahme sich lohnt, bevor Geld in Hardware fließt. Manchmal ist ein größerer Server danach trotzdem die richtige Antwort, dann aber mit Begründung. Mehr dazu unter Gewachsene Anwendungen modernisieren.

Der Beitrag Wenn die Software langsam wird: erst die Arbeit prüfen, dann die Hardware erschien zuerst auf Digifinity.

Wenn die Schnittstelle zwischen zwei Systemen hakt: was vor der Reparatur geklärt sein sollte

Paul Engelhardt — Tue, 27 Oct 2026 03:56:37 +0000

Wenn die Schnittstelle zwischen zwei Systemen hakt: was vor der Reparatur geklärt sein sollte

„Die Schnittstelle funktioniert nicht richtig.“

Diesen Satz hört man, wenn Daten zwischen zwei Systemen nicht so ankommen, wie sie sollen. Aufträge fehlen, Mengen stimmen nicht, ein Status passt nicht zum anderen. Am Ende prüft jemand von Hand nach, obwohl genau das die Schnittstelle überflüssig machen sollte.

Der naheliegende Verdacht ist die Technik. Manchmal stimmt er. Manchmal liegt die Ursache woanders. Bevor man repariert, lohnt es sich, beides auseinanderzuhalten.

Was technisch schiefgehen kann

Technische Fehlerquellen gibt es reichlich. Ein Datumsformat wird auf beiden Seiten unterschiedlich gelesen. Ein Feld ist im einen System Pflicht und im anderen optional. Ein Sonderzeichen bricht die Übertragung ab. Ein System ist kurz nicht erreichbar, und niemand merkt, dass in dieser Zeit Daten verloren gegangen sind. Ein Hersteller ändert mit einem Update seine Schnittstelle.

Solche Fehler sind ärgerlich, aber greifbar. Man kann ihnen technisch nachgehen und sie meist gezielt beheben. Eine gut gebaute Schnittstelle meldet sie außerdem, statt still Daten zu verlieren, und weiß, was zu tun ist, wenn die Gegenseite nicht antwortet.

Was die Daten bedeuten

Schwieriger wird es, wenn technisch alles korrekt übertragen wird und das Ergebnis trotzdem nicht stimmt.

Ein typisches Bild: Der Vertrieb arbeitet mit einem Programm für Angebote, die Produktion plant mit einem anderen System. Ist ein Auftrag „bestätigt“, geht er an die Produktion. Der Vertrieb meint damit, dass der Kunde zugesagt hat. Die Produktion liest „bestätigt“ als „kann eingeplant werden“ und plant Aufträge ein, bei denen Material und Termin noch gar nicht geklärt sind. Die Schnittstelle überträgt das Feld fehlerfrei. Das Problem steckt in einer Annahme, die jede Seite für selbstverständlich hält.

Ähnlich ist es bei der Frage, welches System im Zweifel recht hat, wenn eine Adresse oder ein Preis in beiden gepflegt wird. Oder ab wann ein Angebot eigentlich ein Auftrag ist.

Solche Fragen sammeln sich oft genau an der Stelle, an der aus einem Angebot ein Fertigungsauftrag wird. Dort ist häufig niemand richtig zuständig, weil diese Stelle in keinem Organigramm auftaucht. Gerade im Mittelstand funktioniert das lange erstaunlich gut, über kurze Wege und Zuruf. Erst wenn eine Schnittstelle den Zuruf ersetzen soll, fällt auf, dass die Regel nie aufgeschrieben wurde.

Was vor dem Bau geklärt sein sollte

Ob eine Schnittstelle neu gebaut oder repariert wird, vorher sollten ein paar Fragen beantwortet sein:

Welche Daten müssen wann von wo nach wo?
Was bedeuten die wichtigsten Felder und Zustände auf beiden Seiten?
Welches System hat im Zweifel recht?
Wer verlässt sich auf die übertragenen Daten, und was passiert, wenn etwas nicht ankommt?
Wer ist zuständig, wenn ein Fehler gemeldet wird?

Die Antworten bestimmen auch, wie viel Schnittstelle nötig ist. Nicht jede Verbindung muss in Echtzeit laufen. Manchmal reicht ein nächtlicher Abgleich. Auch muss nicht jeder Sonderfall automatisch verarbeitet werden. Für seltene Ausnahmen kann es reichen, dass die Schnittstelle sie meldet und jemand sie von Hand erledigt. Und wenn nur ein paar Datensätze im Monat übertragen werden, kann ein sauberer Export die vernünftigere Lösung sein als eine Schnittstelle, die gebaut, überwacht und gepflegt werden muss. Entscheidend ist, was der Prozess tatsächlich braucht.

Wer für den ganzen Weg zuständig ist

Bei einer gestörten Schnittstelle hat oft jeder seinen Teil richtig gemacht. Der Vertrieb hat seine Daten gepflegt, die Produktion ihre. Die IT hat umgesetzt, was im Ticket stand. Und trotzdem hakt es genau dort, wo alles zusammenkommen müsste.

Verantwortung für einzelne Teile lässt sich gut verteilen. Für das Ergebnis braucht es jemanden im Unternehmen, der den ganzen Weg im Blick hat, vom Angebot bis zum Fertigungsauftrag, über alle Systeme hinweg. Das muss keine neue Stelle sein. Es sollte aber klar sein, wer entscheidet, wenn zwei Bereiche „bestätigt“ unterschiedlich verstehen.

Hakt bei Ihnen eine Verbindung zwischen zwei Systemen, schaue ich mir beides an: die Technik und die Annahmen dahinter. Ich verfolge den Weg der Daten über alle beteiligten Systeme, kläre mit den Bereichen, was die Daten bedeuten, und baue danach, was der Prozess wirklich braucht. Mehr dazu unter Systeme verbinden.

Der Beitrag Wenn die Schnittstelle zwischen zwei Systemen hakt: was vor der Reparatur geklärt sein sollte erschien zuerst auf Digifinity.

Wann sollte man Legacy-Software modernisieren?

Paul Engelhardt — Tue, 27 Oct 2026 03:55:36 +0000

Wann sollte man Legacy-Software modernisieren?

„Das läuft doch noch.“

Diesen Satz hört man über Legacy-Software: Anwendungen, die seit Jahren im Einsatz sind, auf älterer Technik laufen und tief in die Prozesse eingebunden sind. Meist ist er vernünftig. Die Anwendung tut, was sie soll. Niemand beschwert sich laut. Eine Modernisierung kostet Geld, bindet Leute und bringt eigene Risiken mit. Also bleibt alles, wie es ist.

Das ist häufig die richtige Entscheidung. Schwierig ist, den Moment zu erkennen, an dem aus „noch nicht“ langsam „zu spät“ wird. Er kündigt sich selten laut an.

Wann Abwarten richtig ist

Was zuverlässig arbeitet und sich weiter sicher betreiben lässt, muss nicht ersetzt werden, nur weil es alt ist. Eine Anwendung, die stabil läuft, Sicherheitsupdates bekommt und sich bei Bedarf noch ändern lässt, darf in Ruhe weiterlaufen.

Anders sieht es aus, wenn verwendete Komponenten keine Sicherheitsupdates mehr bekommen. Dann ist Abwarten kein neutraler Zustand mehr, sondern ein Risiko, das mit jedem Monat bleibt.

Die Kosten zeigen sich vor dem Ausfall

Würde eine alte Anwendung einfach kaputtgehen, wäre die Sache klar. Dann würde jeder handeln. Die Kosten des Wartens zeigen sich aber meist früher, an Stellen, die für sich allein harmlos aussehen.

Das deutlichste Zeichen: Neue Entscheidungen fangen an, Rücksicht auf alte Probleme zu nehmen.

Ein Bericht wird umständlicher gebaut, weil die Daten an einer Stelle nicht sauber zusammenlaufen. Ein neuer Prozess bekommt eine Ausnahme, damit der alte nicht angepasst werden muss. Eine Auswertung, die eigentlich einfach wäre, braucht einen Zwischenschritt, den niemand genau erklären kann. Eine neue Schnittstelle berücksichtigt einen alten Sonderfall, und der nächste Prozess richtet sich wieder danach.

Jede dieser Entscheidungen ist für sich vernünftig. Im Einzelfall würde man sie genauso treffen. Das Problem ist die Summe. Irgendwann baut man nicht mehr um das ursprüngliche Problem herum, man baut auf den Umwegen weiter.

Wenn mehrere Umwege dieselbe Ursache haben

Einzeln betrachtet wirken solche Umwege wie verschiedene kleine Probleme. Oft gehen mehrere davon auf dieselbe Stelle zurück.

Herausfinden lässt sich das mit einer einfachen Frage, die man bei jedem Umweg stellt: Warum gibt es ihn? Und dann noch einmal: Warum gibt es das, was ihn nötig gemacht hat? Häufig landen mehrere Antworten am selben Punkt. Ein Datenmodell, das eine Variante nicht kennt, die es im Geschäft längst gibt. Eine Kundennummer, die in zwei Systemen unterschiedlich geführt wird. Ein Modul, an das sich niemand mehr herantraut und um das deshalb alle herumarbeiten.

Wer diese Stelle findet, hat einen Hebel. Eine einzelne Korrektur dort kann mehrere Umwege auf einmal überflüssig machen.

Mit jeder neuen Entscheidung wird das schwieriger. Jeder Umweg, auf dem etwas Neues aufbaut, ist eine weitere Abhängigkeit, die bei der Korrektur mitbedacht werden muss. Irgendwann lässt sich die ursprüngliche Stelle nicht mehr isoliert ändern, weil schlicht zu viel daran hängt.

Ab hier wird Warten teuer.

Was man tun kann, ohne gleich alles umzubauen

Der erste Schritt kostet wenig: die Umwege sichtbar machen. Wo gibt es sie, seit wann, und was hängt an ihnen? Schon eine einfache Liste zeigt, ob sich etwas an einer Stelle häuft.

Bei jedem neuen Vorhaben lohnt dann eine zusätzliche Frage: Bauen wir gerade um ein altes Problem herum? Das muss nicht falsch sein. Man sollte nur wissen, dass man es tut, und was es für eine spätere Korrektur bedeutet.

Nicht jeder Umweg muss weg. Einer, der stabil ist, wenig Aufwand verursacht und auf dem nichts weiter aufbaut, kann bleiben. Handeln sollte man dort, wo sich Umwege häufen und neue Vorhaben auf ihnen aufsetzen.

Modernisieren oder neu bauen?

Modernisieren heißt nicht automatisch neu bauen. Oft reicht es, ein Datenmodell zu bereinigen, ein besonders problematisches Modul zu überarbeiten oder einzelne Komponenten zu aktualisieren, Schritt für Schritt und mit Blick auf den laufenden Betrieb. Ein Neubau kann sinnvoll sein, wenn die Ursache so tief sitzt, dass Korrekturen an einzelnen Stellen nicht mehr reichen, wenn sich die verwendete Technik nicht mehr sicher aktualisieren lässt oder wenn das Geschäft heute etwas anderes braucht als das, wofür das System gebaut wurde. Ob er gegenüber einem größeren Umbau die bessere Wahl ist, entscheiden Aufwand, Risiken und das, was der laufende Betrieb während des Umstiegs verkraftet.

Ob sich bei Ihnen Umwege an einer Stelle häufen, zeigt eine Bestandsaufnahme. Dafür gehe ich mit den Beteiligten die Umwege durch und verfolge sie bis zu ihrer Ursache. Danach haben Sie eine Grundlage für die Entscheidung, wo Handlungsbedarf besteht, welche Änderungen sinnvoll sind und was vorher noch genauer untersucht werden sollte. Mehr dazu unter Gewachsene Anwendungen modernisieren.

Der Beitrag Wann sollte man Legacy-Software modernisieren? erschien zuerst auf Digifinity.

Standardsoftware oder Individualsoftware: wann sich eine eigene Lösung lohnt

Paul Engelhardt — Tue, 27 Oct 2026 03:54:27 +0000

Standardsoftware oder Individualsoftware: wann sich eine eigene Lösung lohnt

Irgendwann stellt sich in vielen Unternehmen die Frage: Kaufen wir eine fertige Software, oder lassen wir uns etwas Eigenes bauen? Meist kommt sie auf, weil die bisherige Lösung hakt. Das System kann etwas nicht, oder die Mitarbeitenden arbeiten an ihm vorbei.

Der Unterschied ist schnell erklärt. Standardsoftware ist für viele Unternehmen mit ähnlichen Anforderungen gebaut, man kauft oder mietet sie fertig. Individualsoftware wird für ein Unternehmen und seine Prozesse entwickelt.

„Standard oder individuell?“ ist dafür allerdings zu grob gefragt. Kaum ein Unternehmen arbeitet ausschließlich mit dem einen oder dem anderen. Hilfreicher ist eine andere Frage: An welchen Stellen sollte sich das Geschäft dem Tool anpassen, und an welchen das Tool dem Geschäft?

Wofür Standardsoftware gemacht ist

Ich verdiene mein Geld mit Individualsoftware. Trotzdem rate ich öfter zur Standardlösung, als man vielleicht erwartet. Wenn eine Aufgabe nach Standardsoftware aussieht und sich eine eigene Entwicklung voraussichtlich nicht rechnet, sage ich das.

Buchhaltung, Lohnabrechnung, Zeiterfassung, in vielen Fällen auch Warenwirtschaft oder CRM: Hier haben viele Unternehmen ähnliche Anforderungen, und gute Hersteller bilden sie seit Jahren ab. Sie kümmern sich um Gesetzesänderungen, Sicherheitsupdates und Weiterentwicklung und verteilen diesen Aufwand auf viele Kunden. Wer so etwas selbst nachbaut, bezahlt die Entwicklung und danach all das, was sonst der Hersteller übernimmt.

Für solche etablierten Prozesse lohnt es sich deshalb, zuerst vorhandene Produkte zu prüfen. Das heißt nicht, dass Warenwirtschaft oder CRM nie individuell sein dürfen. Gerade dort gibt es Betriebe mit sehr eigenen Anforderungen. Dann sollten die besonderen Anforderungen den zusätzlichen Aufwand einer eigenen Lösung aber auch tragen.

Ein Stück Anpassung ist normal

Wer Standardsoftware einführt, passt sich an. Felder heißen anders, Schritte laufen in einer anderen Reihenfolge, manche Gewohnheit fällt weg. Das ist nicht automatisch ein Verlust. Oft werden Abläufe dabei einheitlicher, und manches, was nur gewachsen war, verschwindet zu Recht.

Auch eine kleine Zusatzliste neben dem System ist noch kein Grund, etwas Eigenes zu bauen. Solange sie überschaubar bleibt und klar ist, wer sie pflegt, ist sie oft die günstigste Lösung.

Wann das Tool anfängt, das Geschäft zu formen

Problematisch wird es, wenn die Anpassung nicht mehr aufhört. Wenn das Geschäft nach und nach so läuft, wie die Software es vorsieht, und dabei Vorteile verliert, die es vorher hatte.

Ein paar Zeichen sprechen dafür, genauer hinzuschauen:

Neben dem System entstehen immer mehr Listen, ohne die der Ablauf nicht mehr funktioniert.
Felder werden für etwas anderes benutzt, als sie gedacht sind, weil das passende Feld fehlt.
Es gibt Arbeitsschritte, die nur existieren, weil die Software sie verlangt.
Bestimmte Vorgänge kann nur noch erledigen, wer die nötigen Umwege kennt.
Ein Sonderfall, den Ihre Kunden schätzen, wird abgeschafft, weil er nicht ins System passt.

Keines dieser Zeichen beweist, dass eine eigene Lösung nötig ist. Sie zeigen, wo Reibung entsteht. Ob es sich lohnt, sie zu beseitigen, ist eine wirtschaftliche Frage.

Besonders ernst ist das letzte Zeichen, wenn der Sonderfall ein echter Vorteil für Ihre Kunden ist. Wo ein Unternehmen anders arbeitet als der Rest der Branche und genau daraus Geschwindigkeit, Qualität oder einen Vorteil beim Kunden zieht, kostet eine Software, die das glattbügelt, mehr als ihren Kaufpreis.

Erst die naheliegenden Wege

Zwischen „der Standard passt nicht“ und „wir bauen selbst“ liegen noch andere Möglichkeiten. Manchmal lässt sich die vorhandene Software anders einstellen. Manchmal bietet der Hersteller ein Modul oder eine Erweiterung für diesen Fall. Und manchmal passt ein anderes Standardprodukt besser zum eigenen Prozess. Was davon bei Ihrem Produkt möglich ist, weiß am ehesten der Hersteller. Diese Wege sind meist günstiger und gehören geprüft, bevor gebaut wird.

Mit einer Grenze: Je tiefer Anpassungen in den Kern einer Standardsoftware eingreifen, desto aufwendiger werden die Updates des Herstellers. Irgendwann hat man die Nachteile beider Welten.

Abhängig ist man in beiden Fällen

Auch Standardsoftware hat ihren Preis, und der steht nicht immer im ersten Angebot. Lizenzen werden teurer, Funktionen wandern in größere Pakete, ein Produkt wird eingestellt oder nach einer Übernahme anders weiterentwickelt. Wer seine Prozesse ganz auf ein Produkt ausrichtet, hängt an diesen Entscheidungen.

Eine eigene Lösung schafft eine andere Abhängigkeit: von den Menschen, die sie gebaut haben und betreuen. Ob das zum Problem wird, entscheidet sich an ein paar Fragen. Hat Ihr Unternehmen den Quellcode? Ist festgehalten, warum etwas so gebaut wurde? Könnte ein anderer Entwickler übernehmen? Was passiert, wenn das nicht geklärt ist, beschreibe ich im Artikel Software übernehmen, wenn der Entwickler weg ist.

Rechnet sich eine eigene Lösung?

Für eine erste Einschätzung braucht es keine aufwendige Rechnung, aber klare Antworten auf ein paar Fragen. Bei einer größeren Investition gehört später ein genauerer Vergleich dazu.

Wie oft entsteht die Mehrarbeit? Ein Umweg, der einmal im Monat zehn Minuten kostet, ist etwas anderes als einer, der jeden Tag bei jedem Auftrag anfällt.

Welche Fehler und Verzögerungen verursacht sie? Doppelt erfasste Daten weichen voneinander ab, Rückfragen kosten Zeit, Aufträge bleiben liegen, weil eine Information in der falschen Liste steht.

Was würde möglich? Eine eigene Lösung spart nicht nur Arbeit. Sie kann auch erlauben, Aufträge schneller zu bestätigen, mehr Varianten anzubieten oder mit denselben Leuten mehr abzuwickeln.

Was steht dem gegenüber? Eine eigene Lösung kostet nicht nur die Entwicklung. Sie muss eingeführt, betrieben, aktualisiert und über Jahre weiterentwickelt werden. Und es muss jemand da sein, der das übernimmt.

Eine eigene Lösung lohnt sich, wenn ihr Nutzen Entwicklung, Einführung und laufenden Betrieb rechtfertigt. Eingesparte Arbeit, vermiedene Fehler und neue Möglichkeiten gehören dabei zusammen in die Rechnung. Schon bei der Klärung der Anforderungen zeigt sich meist, in welche Richtung es geht.

Der Mittelweg

In vielen Fällen ist die beste Antwort eine Mischung. Die Standardsoftware bleibt für das, was sie gut kann: Buchhaltung, Stammdaten, Bestellwesen. Daneben entsteht ein eigenes Werkzeug für genau den Teil, der den Unterschied macht, etwa eine bestimmte Art der Auftragsplanung oder eine Produktkonfiguration, die so kein Standardprodukt abbildet.

Wichtig ist, dass dieses Werkzeug an die bestehenden Systeme angebunden wird. Sonst entsteht eine weitere Insel, und die Daten werden wieder von Hand übertragen. Wie das geht, beschreibe ich unter Systeme verbinden. Was vorher geklärt sein sollte, damit die Verbindung im Alltag trägt, steht im Artikel Wenn die Schnittstelle zwischen zwei Systemen hakt.

Wo die Grenze bei Ihnen verläuft, zeigt sich am konkreten Ablauf. Den schaue ich mir mit den Leuten an, die ihn jeden Tag erledigen, und kläre, was eine Lösung wirklich leisten muss, bevor gebaut wird. Ist am Ende ein Standardprodukt die bessere Wahl, sind diese Anforderungen nicht verloren. Sie sind die beste Grundlage, um Produkte zu vergleichen und Anbietern die richtigen Fragen zu stellen. Mehr dazu unter Interne Tools und neue Anwendungen.

Der Beitrag Standardsoftware oder Individualsoftware: wann sich eine eigene Lösung lohnt erschien zuerst auf Digifinity.

Selbst gebaute Tools im Betrieb: wann einfach machen, wann prüfen lassen

Paul Engelhardt — Tue, 27 Oct 2026 03:53:29 +0000

Selbst gebaute Tools im Betrieb: wann einfach machen, wann prüfen lassen

Eine Auswertung für das nächste Meeting. Ein Rechner für die eigene Kalkulation. Eine Liste, die endlich nicht mehr auf drei Excel-Dateien verteilt ist. Solche Werkzeuge baut man sich heute mit KI an einem Abend, ohne Entwickler und ohne ausgefeilte Architektur.

Das ist in Ordnung. Ein Tool, das nur Sie selbst benutzen, muss nicht gebaut sein, als müsse es zehn Jahre laufen. Wenn es tut, was es soll, reicht das. Geht es kaputt, baut man es neu.

Das gilt mit zwei Einschränkungen. Die Daten darin müssen sich leicht ersetzen lassen. Schon die Kalkulation oder die zusammengeführte Liste kann nach ein paar Monaten Einträge enthalten, die es sonst nirgends mehr gibt. Und an den Ergebnissen darf keine Entscheidung hängen, bei der ein Fehler teuer wird.

Das Tool bleibt gleich, seine Rolle wächst

Schwierig wird es, wenn das Tool unverändert bleibt, aber seine Rolle wächst.

Ein Kollege fragt, ob er es auch nutzen kann. Jemand trägt zum ersten Mal Kundendaten ein. Eine andere Abteilung übernimmt die Ergebnisse, ohne sie selbst noch einmal zu prüfen. Oder das Tool soll ins Netz, damit mehr Menschen darauf zugreifen können.

Auf Freelancer-Portalen tauchen inzwischen Anfragen auf wie: „Mit Claude fertig gebaute App, muss nur noch online.“ Das „nur noch“ ist die Stelle, an der es kippt. Mit dem Schritt ins Netz kommen Fragen dazu, die vorher keine Rolle gespielt haben: wer sich anmelden kann, wer was sieht und wer sich kümmert, wenn das Tool nicht erreichbar ist.

In keinem dieser Fälle muss sich eine Zeile Code ändern. Was sich ändert, ist die Tragweite, wenn etwas schiefgeht.

Vier Fragen zum Einordnen

Wer hängt davon ab? Dazu gehören nicht nur die Menschen, die das Tool bedienen, sondern auch die, die von seinen Ergebnissen betroffen sind. Rechnet Ihr eigener Kalkulationsrechner falsch, fällt das womöglich niemandem auf, und das Angebot geht trotzdem raus. Arbeiten andere damit oder verlassen sich auf seine Ergebnisse, trifft ein Fehler Menschen, die nicht wissen, wie das Tool entstanden ist und wo seine Grenzen liegen.

Was passiert, wenn es ausfällt? Fällt ein persönlicher Rechner einen Tag aus, rechnet man von Hand. Hängt ein Prozess im Betrieb daran, etwa die Planung oder die Annahme von Aufträgen, steht dieser Prozess still. Und manchmal fällt ein Tool gar nicht sichtbar aus, sondern liefert still falsche Ergebnisse.

Was kostet es, es neu zu machen? Der Code ist mit KI schnell neu geschrieben. Die Daten darin, die Einstellungen und die Abläufe, die sich inzwischen auf das Tool eingestellt haben, sind es nicht. Je länger ein Tool im Einsatz ist, desto mehr hängt an Dingen, die sich nicht neu erzeugen lassen.

Wer kümmert sich, wenn sich etwas ändert? Angebundene Dienste ändern ihre Schnittstellen, verwendete Bibliotheken brauchen Sicherheitsupdates, Anforderungen wachsen. Irgendwer muss das Tool dann anpassen. Ist das die Person, die es an einem Abend gebaut hat, und ist sie noch da, wenn es so weit ist?

Die vier Fragen sind in zwei Minuten gestellt. Am einfachsten stellt man sie, sobald man überlegt, ob das Tool auch für andere nützlich wäre.

Drei Situationen

Wie unterschiedlich die Antworten ausfallen, zeigen drei typische Situationen.

Ein Rechner, den nur Sie nutzen. Er nimmt Eingaben, rechnet und zeigt ein Ergebnis. Gespeichert wird nichts, jedes Ergebnis lässt sich jederzeit neu erzeugen. Lassen sich die Ergebnisse leicht kontrollieren und hat ein Fehler überschaubare Folgen, wäre eine aufwendige Prüfung meist unverhältnismäßig. Dann reicht es oft, ein paar Ergebnisse von Hand nachzurechnen. Fließen die Ergebnisse direkt in Angebote oder Bestellungen, lohnt ein genauerer Blick.

Eine gemeinsame Liste, die mehrere Kollegen pflegen. Jetzt verändern mehrere Menschen dieselben Daten. Dann sollte klar sein, wer was sehen und ändern darf und ob es eine Sicherung gibt, falls jemand versehentlich etwas überschreibt oder löscht. Das lässt sich oft mit überschaubarem Aufwand klären. Geklärt sein sollte es, bevor die Liste die einzige Quelle für diese Daten ist.

Eine Anwendung mit Kundenzugang oder mit Ergebnissen, auf die sich ein Prozess verlässt. Kunden melden sich an und sehen ihre Aufträge oder Rechnungen. Oder die Produktion plant nach dem, was die Anwendung ausgibt. Hier reichen ein paar erfolgreiche Testläufe nicht mehr. Dass die Anwendung im normalen Gebrauch funktioniert, sagt nichts darüber, ob ein Kunde die Daten eines anderen sehen kann, wenn er die Adresse im Browser leicht verändert, oder was passiert, wenn ein angebundener Dienst nicht antwortet. Das muss man gezielt prüfen. Dafür sollte jemand mit entsprechender Erfahrung draufschauen, der die Anwendung nicht selbst gebaut hat.

Die Folgen bestimmen den Prüfbedarf

Wie viel Prüfung ein Tool braucht, hängt vom Einsatz und seinen möglichen Folgen ab. Ob es mit KI, mit einem Baukasten oder von Hand entstanden ist, spielt dafür kaum eine Rolle. Für die Prüfung selbst ist die Bauweise trotzdem wichtig. Jede Plattform und jede Art zu bauen hat ihre typischen Schwachstellen, und wer prüft, sollte sie kennen.

Eine Prüfung muss nichts finden

Wer jemanden holt, um eine Anwendung zu prüfen, erwartet ein Ergebnis. Und wer geholt wird, kommt ungern mit leeren Händen zurück. Ein Bericht mit zwölf Punkten sieht nach Arbeit aus, einer mit „keine wesentlichen Risiken“ schnell nach verschwendetem Geld.

Dazu kommt: Auch mir fallen in fremdem Code nach einer Stunde zehn Dinge auf, die ich anders gebaut hätte. Das heißt noch lange nicht, dass eines davon ein Problem für Ihren Einsatz ist.

Deshalb gehört zu einer brauchbaren Prüfung, dass „in den geprüften Bereichen keine wesentlichen Risiken für den vorgesehenen Einsatz“ ein zulässiges Ergebnis ist. Manchmal ist es sogar das wertvollste. Man muss es vorher nur erlauben.

Bevor Ihr Tool diesen Schritt macht, kann ich es mir ansehen. Im ersten Gespräch klären wir, wer es nutzt, welche Daten es verarbeitet und wo es laufen soll. Manchmal zeigt sich schon dort, dass keine Prüfung nötig ist. Mehr dazu unter Selbst gebaute Anwendungen prüfen.

Der Beitrag Selbst gebaute Tools im Betrieb: wann einfach machen, wann prüfen lassen erschien zuerst auf Digifinity.

Software übernehmen, wenn der Entwickler weg ist: die ersten Schritte

Paul Engelhardt — Tue, 27 Oct 2026 03:51:32 +0000

Software übernehmen, wenn der Entwickler weg ist: die ersten Schritte

Eine Anwendung läuft seit Jahren. Sie bildet einen Prozess ab, auf den sich im Betrieb alle verlassen, vielleicht die Auftragsabwicklung, vielleicht die Planung. Gebaut hat sie jemand, der nicht mehr da ist. Der Entwickler hat das Unternehmen verlassen, der Dienstleister hat keine Kapazität mehr, oder die Zusammenarbeit hat schlicht geendet.

Solange alles läuft, fällt das kaum auf. Spätestens bei der ersten Störung oder dem ersten Änderungswunsch stellt sich die Frage, wer sich jetzt darum kümmert. Und schnell steht der Gedanke im Raum, das Ganze neu zu machen.

Das kann am Ende die richtige Entscheidung sein. Als erster Schritt kommt sie meist zu früh.

Was zuerst gesichert werden sollte

Bevor jemand über Neubau oder Weiterentwicklung entscheidet, sollte gesichert sein, was da ist. Die folgenden Punkte sind eine Orientierung. Was zuerst kommt, hängt von der Lage ab. Läuft ein Serververtrag aus oder gibt es keine aktuelle Sicherung der Daten, hat das Vorrang.

Quellcode und Zugänge. Wo liegt der Code? Gibt es ein Repository, auf das Ihr Unternehmen selbst Zugriff hat, oder liegt er nur beim bisherigen Entwickler? Wer kennt die Zugänge zu Server, Datenbank, Domain und den angebundenen Diensten? Solange all das erreichbar ist, kostet das Sichern wenig. Ist ein Zugang erst verloren, wird es aufwendig und manchmal unmöglich.

Betrieb und Sicherungen. Wo läuft die Anwendung, wer bezahlt den Server, und wann läuft welcher Vertrag aus? Gibt es Sicherungen der Daten, und hat schon einmal jemand ausprobiert, ob sie sich zurückspielen lassen?

Wissen im Betrieb. Wer arbeitet täglich mit der Anwendung? Wer kennt die Sonderfälle und weiß, warum ein bestimmter Schritt so ist, wie er ist? Ist der bisherige Entwickler noch erreichbar, lohnt sich ein Gespräch mit ihm, selbst wenn es nur eine Stunde dauert.

Das müssen Sie nicht alles allein zusammentragen, bevor Sie jemanden dazuholen. Wer die Anwendung übernehmen soll, kann beim Sichten und Sichern helfen und sieht schneller, was fehlt und was dringend ist. Gerade wenn Unterlagen fehlen, lohnt es sich, früh jemanden dazuzuholen.

Warum der Code allein nicht reicht

Von außen wirkt so eine Anwendung oft chaotisch. Unklare Namen, Ausnahmen an seltsamen Stellen, Teile, die niemand mehr anfassen will. Mit etwas Kontext sieht es meist anders aus. Hinter vielen Ausnahmen steckt ein Sonderfall, der irgendwann aufgetreten ist, eine Regel für einen bestimmten Kunden oder eine Abhängigkeit zu einem anderen Ablauf. Jemand hat das einmal bewusst so gebaut.

Was davon weder aufgeschrieben noch an jemand anderen weitergegeben wurde, ist mit dem Entwickler gegangen. Der Code zeigt, was passiert, aber selten warum. Eine Übernahme beginnt deshalb mit Verstehen: über den Code, die Daten und Gespräche mit den Menschen, die täglich mit der Anwendung arbeiten. Sie wissen über die Sonderfälle oft mehr als jede Dokumentation.

Das ist auch das Risiko eines schnellen Neubaus. Die sichtbaren Funktionen lassen sich nachbauen. Die Sonderfälle, die das alte System still abgefangen hat, fallen oft erst im neuen auf, als Fehler. Weiterbetreiben ist trotzdem nicht automatisch richtig. Wann ein Umbau oder Neubau die bessere Antwort sein kann, beschreibe ich im Artikel Wann sollte man Legacy-Software modernisieren?.

Was eine erste Einschätzung klärt

Dass eine Anwendung seit Jahren im Einsatz ist, spricht dafür, dass sie Abläufe abbildet, auf die sich der Betrieb verlässt. Ob sie sicher ist, ob sie sich gut ändern lässt und ob sie sich nach einem Ausfall wiederherstellen ließe, sagt das nicht. Das klärt eine erste technische Einschätzung, etwa mit diesen Fragen:

Ist der Code vollständig, und lässt sich die Anwendung daraus neu aufsetzen?
Welche Komponenten bekommen keine Sicherheitsupdates mehr?
Wie sind Zugriffe geregelt, und wer kann was sehen oder ändern?
Lassen sich Anwendung und Daten aus den vorhandenen Sicherungen wiederherstellen?
Wo fehlen Tests oder Wissen, um Änderungen verlässlich zu prüfen?
Was ist dringend, und was kann warten?

Erst danach lässt sich sagen, ob die Anwendung vorerst so weiterlaufen kann oder ob etwas zu tun ist.

Damit das Wissen nicht wieder in einem Kopf liegt

Wer eine Anwendung übernimmt, läuft in eine naheliegende Falle. Er arbeitet sich ein, versteht das System, behebt Fehler, setzt Änderungen um. Und nach einem Jahr liegt das Wissen wieder bei einer einzigen Person. Diesmal bei ihm. Dann ist die Abhängigkeit nur verschoben.

Achten Sie deshalb von Anfang an darauf, dass festgehalten wird, was bei der Einarbeitung herauskommt: warum ein Teil so gebaut ist, welche Sonderfälle es gibt, wo die Grenzen der Lösung liegen. Das macht niemanden beliebig ersetzbar. Aber es erleichtert die nächste Übergabe und hilft schon im Alltag, wenn eine Frage auftaucht und der Betreuer gerade nicht erreichbar ist.

Wenn Sie gerade in dieser Lage sind, helfe ich beim Sichten und Sichern, arbeite mich in die Anwendung ein und sage Ihnen, was solide ist, wo Risiken liegen und was als Nächstes sinnvoll ist. Mehr dazu unter Bestehende Software betreuen.

Der Beitrag Software übernehmen, wenn der Entwickler weg ist: die ersten Schritte erschien zuerst auf Digifinity.