Anpassungen (auch bekannt als “Customizations”) sind in den letzten Jahren sehr in Verruf geraten. silicon.de-Blogger Christian Hestermann verrät, wie Anpassungen ihren Schrecken verlieren.
Horrorgeschichten über komplexe Systeme, die so stark angepasst wurden, dass sie sich jeglicher Weiterentwicklung oder Erwartung widersetzen, haben zu ihrem schlechten Ruf beigetragen. In vielen Fällen ist ein Update oder die Migration auf ein neueres Release oder die routinemäßige Wartung, zum Beispiel das Einspielen von Service Packs oder Patches, ohne riesige Kosten kaum mehr möglich.
Dabei sind Anpassungen an sich nichts Schlechtes. Vor allem in den Bereichen, wo sich die Abläufe in einem Unternehmen von denen in den meisten anderen stark unterscheiden und wo diese Unterschiede dazu beitragen, das Unternehmen im Wettbewerb zu stärken, können Abweichungen von den eventuell zu stark verallgemeinerten Best Practices durchaus sinnvoll sein.
Anpassungen können auf unterschiedlichen Ebenen vorgenommen werden. Änderungen der Benutzeroberfläche, etwa um Felder sinnvoller zu gruppieren und dadurch Fehleingaben zu vermeiden, oder das hinterlegen von Workflows gehören zu den einfacheren. Vom System generierte Dokumente und Reports werden in fast jedem Projekt angepasst. Sehr üblich sind auch Integrationen zu anderen Applikationen oder die Erweiterung von Datenstrukturen um zusätzliche Felder. Folgenschwerer sind Eingriffe in die eigentliche Software, etwa das Umschreiben der Business-Logik auf Code-Ebene.
Durch den fast vollständigen Verzicht auf Anpassungen reduzieren die Unternehmen den Wert der teuren Applikationen. Es ist eigentlich nicht einzusehen, viel Geld für Anwendungen auszugeben, die einen dann in ein striktes Korsett pressen und jegliche Flexibilität im Keim ersticken.
Jedoch bedarf es mindestens dreier Aufgabenfelder, um Anpassungen im Griff zu halten. Zum einen muss es Prozesse und Regeln geben (Stichwort “Governance”), um zu einer Entscheidung darüber zu kommen, wo Anpassungen sinnvoll und zulässig sind und wo sie nur nette aber letztlich unnötige “Sonderlocken” darstellen. Am sinnvollsten ist es, diejenigen, die eine Anpassung vorschlagen, an den dadurch entstehenden langfristigen Kosten zu beteiligen. Darunter dürfen aber nicht nur die ursprünglichen Entstehungskosten verstanden werden, sondern der gesamte erhöhte Aufwand im Lauf des gesamten Lebenszyklus der angepassten Anwendung. Zum zweiten müssen Anpassungen sehr gut dokumentiert werden. Dazu gehört unbedingt eine detaillierte Beschreibung, warum und wozu die Anpassung notwendig ist. Nur so kann langfristig entschieden werden, ob Anpassungen nach längerer Zeit in den Ruhestand geschickt oder durch erweiterte Funktionalitäten im Standard ersetzt werden können. Zum dritten ist aber auch hilfreich, eine moderne Systemplattform einzusetzen (oder auf diese anzuheben), welche Anpassungen auf den verschiedenen Ebenen besser unterstützt. Eine so genannte modellbasierte Anwendung (“model-driven packaged application”) erlaubt selbst umfangreichere und komplexere Anpassungen der enthaltenen Abläufe und Datenstrukturen auf der Ebene von Metadaten, die einer späteren Release-Anhebung oder dem Einspielen von Fehlerbehebungen nicht im Wege stehen.
Wenn mindestens diese drei Bedingungen erfüllt sind, können Anpassungen ihren Schrecken verlieren und es erlauben, die teuren Anwendungen auf aktuelle Anforderungen besser zuzuschneiden, ohne langfristig in der Sackgasse einer völlig veralteten weil nicht mehr Release-fähigen Software zu enden
