Softwareanpassungen können eine wichtige Lücke schließen. Sie können aber auch eine Standardlösung schrittweise in ein schwer wartbares Einzelstück verwandeln.
Jede Anpassung sollte deshalb einen klaren betrieblichen Zweck haben, in einer vorgesehenen Erweiterungsebene umgesetzt und über ihren gesamten Lebenszyklus verantwortet werden.
Vier Arten von Anpassung unterscheiden
Konfiguration
Felder, Rollen, Status, Regeln oder Ansichten werden mit vorgesehenen Bordmitteln verändert. Das ist meist die updatefreundlichste Form, kann aber bei übermäßiger Komplexität ebenfalls schwer beherrschbar werden.
Erweiterung über vorgesehene Mechanismen
Plugins, Apps, Skripte oder Erweiterungspunkte ergänzen Funktionen, ohne den Produktkern direkt zu verändern. Kompatibilität und Herstellergrenzen müssen trotzdem geprüft werden.
Integration
Andere Systeme liefern oder empfangen Daten und Funktionen über Schnittstellen. Dadurch entstehen zusätzliche Verantwortungsgrenzen, Überwachung und Fehlerwege.
Änderung am Kern oder individuelle Entwicklung
Eigener Code greift tief in das Produkt ein oder ersetzt eine Funktion vollständig. Diese Form bietet große Freiheit, erzeugt aber den höchsten Test-, Wartungs- und Ablösungsbedarf.
Vor jeder Anpassung fünf Fragen beantworten
- Welches konkrete Problem löst sie?
- Warum reicht der Standard nicht aus?
- Ist die abweichende Arbeitsweise fachlich notwendig?
- Welche einfachere organisatorische oder technische Alternative gibt es?
- Wer verantwortet die Anpassung dauerhaft?
Eine Anpassung ist nicht begründet, nur weil Nutzer den bisherigen Ablauf gewohnt sind.
Den Anpassungsgrad bewusst begrenzen
Lege Gestaltungsregeln fest, beispielsweise:
- Standard vor Konfiguration,
- Konfiguration vor Erweiterung,
- Erweiterung vor Eingriff in den Kern,
- jede Abweichung mit Zweck und verantwortlicher Rolle dokumentieren,
- keine doppelte Datenführung ohne begründete Übergangsregel,
- keine produktive Änderung ohne Test und Rückfallmöglichkeit.
Diese Reihenfolge ist keine starre Vorschrift. Sie macht jedoch sichtbar, wann zusätzliche Verantwortung entsteht.
Update- und Releasefähigkeit prüfen
Für jede Anpassung muss klar sein:
- Welche Produktversionen werden unterstützt?
- Was geschieht bei einem Update?
- Wie wird Kompatibilität vorab getestet?
- Welche Anpassungen müssen nachgezogen werden?
- Wie lange darf ein Update verschoben werden?
- Wer entscheidet über Freigabe und Rückfall?
Eine Funktion, die Updates dauerhaft verhindert, kann langfristig mehr Risiko erzeugen als Nutzen.
Testbare Anforderungen formulieren
Beschreibe Anpassungen als Anwendungsszenario mit erwartbarem Ergebnis, nicht nur als Oberflächenwunsch.
Zu testen sind:
- Normalfall,
- fehlende oder falsche Eingaben,
- Berechtigungen,
- parallele Bearbeitung,
- Ausnahme und Abbruch,
- Schnittstellenfehler,
- hohe oder ungewöhnliche Datenmengen,
- Update und Wiederherstellung.
Automatisierte Tests sind besonders wertvoll bei häufigen Releases und geschäftskritischen Regeln. Fachliche Abnahme bleibt trotzdem erforderlich.
Daten und Schnittstellen beherrschen
Kläre:
- welches System welche Daten führt,
- wie Datenmodelle und Begriffe abgebildet werden,
- wie Dubletten und widersprüchliche Stände behandelt werden,
- wie Fehler sichtbar und erneut verarbeitet werden,
- welche Protokolle für Diagnose verfügbar sind,
- wie ein vollständiger Export möglich ist.
Versteckte direkte Datenbankzugriffe oder manuelle Zwischenexporte sind Warnzeichen für fragile Anpassungen.
Dokumentation und Wissen sichern
Dokumentiere mindestens:
- fachlichen Zweck,
- verantwortliche Rolle,
- betroffene Prozesse und Daten,
- technische Umsetzung und Abhängigkeiten,
- Konfiguration und Berechtigungen,
- Test- und Freigabeverfahren,
- Update- und Rückfallweg,
- Betrieb, Überwachung und Support,
- bekannte Grenzen,
- Vorgehen bei Ablösung.
Dokumentation muss so verfügbar sein, dass nicht nur die ursprüngliche Entwicklerin oder der ursprüngliche Dienstleister handlungsfähig bleibt.
Rechte und Lieferfähigkeit vertraglich klären
Bei externer Umsetzung sind unter anderem relevant:
- Nutzungs- und Änderungsrechte,
- Zugriff auf Quellcode und Konfiguration,
- verwendete Komponenten und Lizenzen,
- Entwicklungs- und Betriebsdokumentation,
- Übergabe von Zugängen und Schlüsseln,
- Fehlerbehebung und Reaktionszeiten,
- Unterstützung bei Anbieterwechsel.
Rechtliche Einzelheiten sollten passend zum Projekt fachkundig geprüft werden.
Anpassungen regelmäßig überprüfen
Eine frühere Lücke kann durch neue Standardfunktionen entfallen. Prüfe bei größeren Updates:
- Wird die Anpassung noch genutzt?
- Erfüllt sie weiterhin ihren Zweck?
- Gibt es inzwischen eine einfachere Standardlösung?
- Welche Fehler oder Betriebskosten verursacht sie?
- Kann sie vereinfacht oder entfernt werden?
Typische Risiken
- Individuelle Felder und Status entstehen ohne gemeinsames Datenmodell.
- Jede Nutzergruppe erhält eine eigene Prozessvariante.
- Anpassungen werden direkt produktiv vorgenommen.
- Ein Dienstleister allein kennt Architektur und Betrieb.
- Updates werden aus Angst vor Konflikten dauerhaft vermieden.
- Temporäre Übergangslösungen werden zum unbefristeten Kernprozess.
- Niemand kennt die Gesamtheit voneinander abhängiger Erweiterungen.
Eine gute Anpassung ist nicht nur heute passend. Sie bleibt verständlich, testbar, updatefähig und entfernbar, wenn sich die Organisation weiterentwickelt.