Kundenindividuelle Entwicklungen – also maßgeschneiderte Softwarelösungen, Anpassungen bestehender Systeme oder spezielle Schnittstellen – bringen im Third-Level-Support ganz eigene, oft sehr anspruchsvolle Herausforderungen mit sich. Diese unterscheiden sich deutlich von Standardlösungen, weil sie meist keine allgemeingültige Dokumentation, einen Community-Support oder Herstellerunterstützung bieten.
Im Folgenden zeigen wir Ihnen die wichtigsten spezifischen Herausforderungen im Third-Level-Support bei kundenindividuellen Entwicklungen auf.
Fehlende oder unzureichende Dokumentation
Individuell entwickelte Lösungen sind oft schlecht oder gar nicht dokumentiert – insbesondere, wenn sie historisch gewachsen sind oder durch externe oder ehemalige Entwickler umgesetzt wurden, die nicht mehr verfügbar sind.
Dadurch müssen sich die Mitarbeitenden des Third-Level-Supports mühsam in unbekannte Codes oder Prozesse einarbeiten. Anstehende Änderungen sind dann besonders risikoreich, weil Abhängigkeiten nicht klar erkennbar sind. Zudem gibt es in der Regel keine klaren Standards, denn jede Lösung funktioniert anders.
Know-how konzentriert auf einzelne Personen
Bei der Umsetzung von kundenindividuellen Entwicklungen gibt es häufig nur wenige Personen mit tiefem Fachwissen über die einzelne Lösung. Wenn diese Mitarbeitenden ausfallen oder das Unternehmen verlassen, entsteht oft eine kritische Wissenslücke.
Infolge eines solchen Wissensmonopols entsteht eine hohe Abhängigkeit von Einzelpersonen, zudem gestaltet sich die Einarbeitung neuer Mitarbeiter als langwierig. Dadurch entstehen oft Risiken für den Support, wenn Kollegen wegen Krankheit oder aufgrund eines Personalwechsels wegfallen.
Keine Standard-Supportprozesse anwendbar
Individuelle Lösungen entziehen sich oft den üblichen Ticket-, Eskalations- oder Troubleshooting-Prozessen, weil sie nicht in gängige ITIL (Information Technology Infrastructure Library )- oder Herstellerprozesse eingebunden sind oder werden können.
Aus diesem Grund müssen Fehlerbilder oft komplett neu interpretiert und analysiert werden und es ist kein Hersteller-Support möglich, weil die Lösung intern entwickelt wurde. Standard-Tools wie z. B. Monitoring oder Logging sind möglicherweise nicht angepasst.
Komplexe Abhängigkeiten und Sonderfälle
Individuelle Entwicklungen greifen häufig tief in vorhandene Systeme ein oder interagieren mit anderen Schnittstellen, Datenbanken, Diensten oder Hardware.
Infolgedessen können unvorhersehbare Seiteneffekte bei Änderungen oder Updates entstehen. Deshalb ist eine enge Abstimmung mit anderen Teams nötig wie der Datenbankadministration oder der Schnittstellenentwicklung. Die einzelnen Anpassungen müssen kundenindividuell getestet und abgesichert werden, damit es kundenseitig keine Probleme gibt.
Langsame Reproduzierbarkeit von Fehlern
Fehler in kundenindividuellen Systemen treten oft nur unter bestimmten Umständen auf, die schwer zu reproduzieren sind – etwa bei bestimmten Nutzerdaten, Konstellationen oder Geschäftsprozessen.
Dadurch müssen die Mitarbeitenden im Third-Level-Support viel Zeit mit dem Aufbau von Testumgebungen und Szenarien verbringen. Zudem müssen Live-Daten analysiert werden, was Datenschutz oder Sicherheit betreffen kann. Außerdem ist es nicht immer möglich, Fehler live ausfindig zu machen. Oftmals treten Fehler nur beim Kunden auf und sind nicht intern simulierbar, was die Analyse deutlich erschwert.
Hoher Abstimmungsaufwand mit dem Kunden
Da es sich um individuell entwickelte Lösungen handelt, hat der Kunde ein Mitspracherecht bei nahezu jeder Änderung – vom Fix bis zum Update.
Das bedeutet, dass Änderungen intensiv abgesprochen und vom Kunden freigegeben werden müssen. Aufgrund dessen sind Verzögerungen durch kundeninterne Prozesse oder Ansprechpartner möglich. Deshalb ist bei Fehlern eine schnelle Bearbeitung eingeschränkt, wenn die Zustimmung oder Datenfreigaben fehlen.
Testbarkeit und Qualitätssicherung
Individuelle Entwicklungen haben oft keine automatisierten Tests oder Staging-Systeme. Änderungen müssen also händisch getestet werden, was zeitaufwendig und fehleranfällig sein kann.
Man muss hier also einen höheren Aufwand für Regressionstests und die Qualitätssicherung einplanen. Denn die kundenindividuellen Entwicklungen bergen die Gefahr, bestehende Funktionen unbeabsichtigt zu beeinflussen. Auch Updates müssen oft individuell ausgeliefert und geprüft werden.
Technische Schulden und veraltete Technologien
Viele maßgeschneiderte Systeme sind jahrelang im Einsatz, ohne modernisiert zu werden. Oft basieren sie auf alten Frameworks, nicht mehr gepflegten Bibliotheken oder benutzerdefinierten Workarounds.
Das hat zur Folge, dass die Wartung zunehmend schwierig oder sogar unmöglich wird. Deshalb lassen sich Sicherheitslücken oft schwer schließen. Trotzdem bekommen viele Systeme kein Update, da die Modernisierungen teuer sind und meist im Live-System durchgeführt werden müssen.
Fazit: Maßarbeit mit viel Verantwortung
Der Third-Level-Support ist bei kundenindividuellen Entwicklungen oft gleichzeitig Entwickler, Architekt, Analyst und Troubleshooter. Die Verantwortung ist groß, da kleinste Änderungen gravierende Auswirkungen haben können und Fehler direkt auf die individuelle Lösung des Kunden zurückfallen.
Um diese Herausforderungen zu meistern, helfen vor allem eine saubere und laufend aktualisierte Dokumentation sowie der Wissensaustausch im Team wie z. B. durch Code Reviews, ein Wiki oder Pair Programming. Zudem können automatisierte Tests und Staging-Umgebungen auch im Kundenkontext dazu beitragen, Anfragen und Probleme schneller lösen zu können. In einigen Fällen ist es zudem hilfreich, ein Projekt- und Kundenmanagement aufzubauen, um Anforderungen und die Kommunikation zwischen dem Third-Level-Support und den Kunden zu steuern. Ein durchdachtes Change-Management mit Rollback-Möglichkeiten erhöht außerdem die Transparenz und Änderungen können schneller rückgängig gemacht werden.