Technical Dept: Ein Konzept aus der Software-Entwicklung
Wird bei der Entwicklung und Wartung von Software Zeit oder Geld gespart, indem z.B. Standards nicht eingehalten wurden, entsteht eine technische Schuld. Die Entstehung dieser Schulden ist dabei ganz unterschiedlich: Es können Code-Praktiken verletzt werden, unpassende Plattformen gewählt werden, beim Testing gespart werden oder – weitverbreitet – die Lösung nicht sauber dokumentiert sein.
Ähnlich wie bei einem Kredit, ist auch die technische Schuld mit einem Zins belegt, wird also im Verlauf der Zeit immer grösser. Ist eine Lösung ungenügend dokumentiert, wird die Behebung dieses Umstands laufend aufwändiger, weil beteiligte Personen wechseln und die Lösung über die Zeit weiterentwickelt wird.
Ein ERP das End of Life ist, ist auch eine technische Schuld
Eine ERP-Software ist ein Kernsystem eines Unternehmens, das besonders sorgfältig auf technische Schulden hin beobachtet werden sollte. Selbst wenn die Implementierung nahe am Standard der Software erfolgt ist, entwertet sich die Lösung über die Zeit. Jede Software verfügt über einen Lebenszyklus, der oftmals bereits durch sich verändernde Umsysteme festgelegt ist. Die meisten ERP-Systeme entwerten sich pro Jahr um 15 – 20% ohne, dass man die Wartung vernachlässigt.
Eine ERP-Lösung kann über die Zeit nicht nur wertlos, sondern zu einer technischen Schuld werden: Die Gründe dafür können Workarounds sein, die nie korrigiert werden, eine veraltete Plattform, nicht durchgeführte Updates, schnelle Bugfixes, mangelnde Dokumentation oder unsaubere Stammdaten etc. sein.
Das Resultat ist, dass der Betrieb der Lösung laufend teuer wird. Die Fehlersuche und Fehlerbehebung sind in einem schlecht dokumentierten System wesentlich aufwändiger. Bei alten Plattformen kommt erschwerend hinzu, dass oft die erfahrensten Entwickler benötigt werden, welche die alten Umgebungen noch kennen.
In Bezug auf die Ablösung ERP-Software können technische Schulden auch bedeuten, dass eine Neueinführung oder ein Upgrade wesentlich teurer ist als die initiale Implementierung. Dies, weil die Schulden zuerst abgetragen werden müssen, indem beispielsweise mittels aufwändigem Reverse Engineering die Prozesse und Funktionsweisen des Legacy Systems eruiert werden müssen.
Technische Schulden können auch bewusst aufgenommen werden
Technische Schulden können, wie finanzielle Schulden auch, absichtlich aufgenommen werden. Wenn zugunsten einer schnelleren Lieferzeit bewusst auf eine saubere Lösung verzichtet wird, kann dies eine sinnvolle Entscheidung sein, sofern die kurzfristigen Gewinne, die gemachte Schulden übersteigen.
Martin Fowler (martinfowler.com) hat zu dieser Einordnung den «TechnicalDebtQuadrant» entworfen, der aufschlüsselt, ob eine Schuld klug (prudent) oder leichtsinnig (reckless) bzw. bewusst oder unbewusst aufgenommen wurde.
In Bezug auf den Lebenszyklus einer ERP-Software angewendet heisst dies, dass die Aufnahme von technischen Schulden nicht per se negativ ist, sondern absichtlich und geplant erfolgen kann. Bei jeder Schuld sollte entsprechend der Abwägung zwischen Schuldenlast bzw. Beseitigungs- oder Minderungskosten gemacht werden. Es kann eine sinnvolle Entscheidung sein, Updates auszusetzen, eine Schnittstelle auf einer alten Technologie zu belassen oder Code nicht zu bereinigen. Wichtig ist, dass die Ermittlung und Bewertung der technischen Schulden kontinuierlich und transparent erfolgt und Entscheide aus rationalen Überlegungen getroffen werden. Ansonsten droht spätestens beim nächsten Release-Wechsel die böse und teure Überraschung.
Bildquellen
TechnicalDebtQuadrant (martinfowler.com)
© vincentdnl 2023