AMS-Übergang und Baseline der Anwendungslandschaft
Beispielhafter Anwendungsfall, keine Fallstudie.
Übernahme von Anwendungen, die wir nicht gebaut haben: Bestand inventarisieren, Umfang und Schweregrade vereinbaren, Wissen übertragen und vor Betriebsbeginn eine Baseline für den Service erfassen.
Das Problem
Die Anwendungen funktionieren, aber die Menschen, die sie verstanden haben, sind weitergezogen, oder der bisherige Anbieter geht. Die Dokumentation ist lückenhaft, Anpassungen sind nicht dokumentiert, und niemand kann sagen, welche Integrationen kritisch sind. Der Support lässt sich nicht verbessern, bevor er verstanden ist.
So läuft es heute
Ein neues Supportteam übernimmt eine Ticket-Warteschlange und ein Netzlaufwerk. Der Wissenstransfer findet in wenigen Gesprächen mit dem scheidenden Team statt. Schweregrad-Definitionen, Servicezeiten und Eskalationswege werden aus dem alten Vertrag angenommen. Die ersten Monate vergehen damit, die Anwendungslandschaft über Incidents neu zu entdecken.
Das Szenario ansehen
Beispielhafter Arbeitsablauf. Mit Untertiteln.
Transkript
- Die Anwendungen laufen, aber die Menschen, die sie verstanden haben, sind weg. Die Dokumentation ist lückenhaft, Anpassungen sind undokumentiert, und niemand kann sagen, welche Integrationen kritisch sind.
- Wir inventarisieren die Anwendungen, vereinbaren Supportumfang und Servicezeiten, dokumentieren Verfahren und Lücken und setzen dann die Ausgangs-Baseline des Service.
- Während der Erfassung ändert sich in der Produktion nichts. Der Verantwortliche gibt die Definitionen vor dem Servicestart frei; die Erkenntnisse speisen ein Verbesserungs-Backlog, das er priorisiert.
- Gemessen an Abdeckung der Anwendungslandschaft und Incidents aus unbekannten Komponenten. Beispielhafter Anwendungsfall. Sprechen wir über Ihren.
Vorgeschlagener Arbeitsablauf
- Die Anwendungslandschaft inventarisieren: Module, Integrationen, Anpassungen, Agenten und die Umgebungen, in denen sie laufen, mit Belegen aus den Systemen statt aus dem Gedächtnis
- Umfang, Schweregrad-Definitionen, Servicezeiten und Verantwortlichkeiten für die Hersteller-Eskalation schriftlich vereinbaren, bevor ein Ticket angenommen wird
- Wissen in Runbooks und eine freigegebene Wissensdatenbank überführen, mit aufgelisteten statt versteckten Lücken
- Die Baseline des Service setzen: aktuelle Incident-Volumen, Lösungszeiten, Release-Rhythmus und bekannte Risiken
- Nach den vereinbarten Definitionen arbeiten, Erkenntnisse festhalten und Verbesserungspunkte vorschlagen, die der Verantwortliche priorisiert
Wo ein Mensch die Kontrolle behält
- Umfang, Schweregrade, Servicezeiten und Eskalationsverantwortlichkeiten werden vom Verantwortlichen freigegeben, bevor der Service beginnt
- Während der Erfassung wird nichts in der Produktion geändert; Erkenntnisse werden festgehalten, nicht an Ort und Stelle behoben
- Das Verbesserungs-Backlog wird vom Verantwortlichen priorisiert, nicht vom Supportteam
Die Plattformzuordnung nennt die Umgebungen, in denen diese Idee geprüft werden kann. Die tatsächliche Umsetzung hängt von Konfiguration, Lizenzen, APIs, Daten und Berechtigungen ab. Der Nutzen wird qualitativ beschrieben; Zahlenangaben erfordern eine dokumentierte Ausgangsbasis.