Wann Custom Development statt Standardsoftware sinnvoll ist

Die Frage „Bauen wir individuell, oder bleibt es beim Standard" taucht in der Praxis an zwei sehr unterschiedlichen Punkten auf.

Workarounds als Architektursignal

Excel-Listen neben dem System, Doppelpflege zwischen zwei Modulen, manuelle Schritte, die niemand mehr hinterfragt, weil sie schon immer Teil des Ablaufs waren. Solche Workarounds entstehen leise, werden zur Routine und tauchen in keiner Auswertung auf.

Was sie anzeigen, ist selten ein Bedienproblem, sondern eine Lücke zwischen System und Prozess. Workarounds entstehen nicht nur in gewachsenen Systemen, in denen sie sich über Jahre angesammelt haben, sondern auch im Umgang mit Standardsoftware, die den Prozess von Beginn an nicht vollständig abgebildet hat. In beiden Fällen sind sie ein Signal, dass die Software dem Geschäft hinterherläuft, statt es zu tragen.

Die Logik der Ergänzung und ihre Grenzen

Die übliche Reaktion auf solche Lücken ist Ergänzung. Custom-Felder im CRM, Zusatzmodule für das ERP, Plugins für den Shop, Schnittstellen zu externen Tools, Abfragen in Excel, weil das Reporting die nötigen Filter nicht hergibt. Jede einzelne dieser Anpassungen ist nachvollziehbar. Sie entsteht aus einer konkreten Anforderung und löst sie pragmatisch.

Das Problem entsteht über die Zeit. Mit jeder Ergänzung verteilt sich Verantwortung auf mehrere Anbieter, mehrere Verträge, mehrere Update-Zyklen. Eine Anpassung am Hauptsystem zieht Reaktionen in den Plugins nach sich, ein Update der Schnittstelle bricht eine Abfrage, ein neuer Release erzwingt Anpassungen, die niemand eingeplant hat. Ab welchem Punkt die Summe dieser Ergänzungen mehr Aufwand verursacht als die ursprüngliche Lücke gekostet hätte, ist selten dokumentiert. Meistens fällt es erst bei der nächsten größeren Änderung auf.

An dieser Stelle wird die Frage „passt der Standard zu uns" oft durch eine andere ersetzt: „wie viel Aufwand investieren wir noch, damit der Standard zu uns passt".

Wann eine Neubewertung sinnvoll ist

Diese Neubewertung lohnt sich an drei strukturellen Punkten.

Erstens, wenn die laufenden Lizenz- und Betriebskosten der Standardsoftware in einer Größenordnung liegen, die mit einer Eigenentwicklung vergleichbar wird. Diese Schwelle ist nicht statisch und lohnt eine regelmäßige Überprüfung.

Zweitens, wenn Daten und Prozesse so eng mit dem System verwoben sind, dass ein späterer Wechsel zu einem anderen Standardprodukt nicht mehr realistisch ist. Vendor Lock-in ist kein neues Phänomen. Mit jedem zusätzlichen Jahr im Betrieb steigen die Kosten eines möglichen Wechsels.

Drittens, wenn die Anpassungen am Standard so umfangreich werden, dass sie selbst Wartungs- und Spezifikationsaufwand verursachen, ohne dass das Ergebnis dem entspricht, was eine eigenentwickelte Lösung leisten würde.

Was Custom Development tatsächlich heißt

An dieser Stelle wird die Diskussion oft auf eine Werkzeugfrage verkürzt. „Bauen oder kaufen", als ginge es um die Auswahl einer Plattform. In der Praxis ist die Entscheidung tiefer angesetzt.

Wer individuell entwickelt, übernimmt nicht in erster Linie Code, sondern Verantwortung. Verantwortung für Spezifikation, weil der Prozess vor der Implementierung verstanden und beschrieben sein muss. Verantwortung für Wartbarkeit, weil eine Anwendung, die heute den Prozess trifft, in fünf Jahren noch erweiterbar sein muss. Verantwortung für Anschlussfähigkeit, weil kein Custom-System isoliert läuft, sondern in eine bestehende Architektur einsteigen muss.

Die Logik dahinter ist dieselbe, [die für die Modernisierung gewachsener Systeme gilt](Link zu Artikel 1): Software folgt dem Prozess, nicht umgekehrt. Eine Custom-Lösung, die den Prozess nicht versteht, hat das gleiche Verhältnis zum Geschäft wie die Standardsoftware, die sie ersetzen soll. Nur teurer.

Der eigentliche Wert liegt deshalb nicht im Code. Er liegt in der Steuerung dahinter. In der Frage, wer entscheidet, was gebaut wird, wer prüft, ob es sich bewährt, und wer dafür sorgt, dass das System auch in zwei Jahren noch zur Organisation passt.

Wann Custom Development nicht die richtige Antwort ist

Das wichtigste Gegenargument folgt aus derselben Logik. Custom Development lohnt sich nicht, weil ein bestehendes System Schwächen hat. Es lohnt sich, wenn der Prozess das Differenzierende ist.

Bei vielen Funktionen ist genau das nicht der Fall. Buchhaltung, Lohnabrechnung, klassische CRM-Funktionalität, allgemeine Dokumentenverwaltung. Diese Bereiche sind in den meisten Unternehmen weitgehend standardisiert, und Standardsoftware bildet sie zuverlässig ab. Eine Eigenentwicklung in diesen Feldern erzeugt keinen Vorteil, sondern Aufwand.

Die ehrliche Frage lautet also nicht „wo könnten wir bauen", sondern „wo unterscheidet sich unser Prozess so deutlich vom Markt, dass eine Eigenentwicklung diesen Unterschied tatsächlich abbilden muss". Wenn diese Antwort konkret ausfällt, ist Custom die richtige Richtung. Wenn sie vage bleibt, lohnt es sich, beim Standard zu bleiben oder die Anpassung an ihn ehrlich zu prüfen.

Prozessanalyse vor Lösungsrichtung

devosphere begleitet Unternehmen in genau diesen Situationen. Von der strukturierten Prozessanalyse bis zur technischen Umsetzung, ob als Modernisierung eines gewachsenen Systems oder als Eigenentwicklung, die den Standard dort ablöst, wo er den Prozess nicht mehr vollständig trägt.

Fazit

Workarounds sind selten ein Bedienproblem und meistens ein Hinweis darauf, dass System und Prozess nicht zueinander passen. Daraus folgt nicht automatisch, dass etwas neu gebaut werden muss. Es folgt aber, dass eine ehrliche Bewertung sinnvoll ist, bevor weitere Ergänzungen entstehen.

Ob ein gewachsenes System modernisiert oder eine Standardlösung durch eine eigene Entwicklung ersetzt wird, im Mittelpunkt steht in beiden Fällen der Prozess, nicht die Technologie. Was sich unterscheidet, ist der Anlass, nicht die Methode. Wie diese Entscheidungslogik bei gewachsenen Systemen konkret aussieht, habe ich im Blogartikel “Legacy-Systeme: Warum Neubau oft der falsche Ansatz ist" beschrieben.

Wenn Sie an einem dieser beiden Punkte stehen, lohnt es sich, den eigenen Prozess strukturiert zu betrachten, bevor eine Lösungsrichtung festgelegt wird.