ITSM für High-Velocity-Teams
Auf der Suche nach einer Lösung für typische Probleme bei ITSM-Systemupgrades
Was ein Produktinhaber über Alternativen zu herkömmlichen ITSM-Systemupgrades gelernt hat.
Ich war Produktinhaber für ein Scrum-Team, das mithilfe eines veralteten ITSM-Systems Funktionen für verschiedene Service-Management-Praktiken entwickelte. Als der letzte Sprint des Kalenderjahres zu Ende ging, hatte mein Team die Gelegenheit, an einem Innovationssprint teilzunehmen, in dem wir neue Funktionen kennenlernen und damit experimentieren konnten. Ich nutzte diesen Innovationssprint, um mir den neuen Release unseres ITSM-Systems anzusehen. Auf den ersten Blick schien es jede Menge neuer Funktionen zu geben. Bei näherem Hinsehen erkannte ich aber, dass die neue Funktionalität unseren Stakeholdern nicht viel nutzen und wahrscheinlich sogar zu größeren technischen Schulden führen würde.
Als klar war, dass unser veraltetes ITSM-System inhärente Supportprobleme haben würde, erkannte ich, dass es nur zwei Optionen gab – damit klar kommen und die Antazida- und Ibuprofen-Vorräte in meiner Schreibtischschublade auffüllen oder nach einer robusteren, flexibleren Lösung suchen.
Allein der Gedanke an die sicherlich zahllosen Treffen mit Prozessverantwortlichen und anderen Stakeholdern bereitete mir stechende Kopfschmerzen. Wenn ich mir überlegte, den Umfang des neuen Release und die Unterbrechung unseres Entwicklungsplans für etwas erklären zu müssen, das letztlich nur minimale Vorteile bringen würde, stand mir der kalte Schweiß auf der Stirn. Unabhängig davon, wie viele Funktionen wir am Ende tatsächlich nutzen konnten, der langwierige Prozess und der Produktivitätsverlust bei Upgrades waren immer dieselben.
Die Herausforderung, ein Upgrade für ein herkömmliches ITSM-System durchzuführen
Für jemanden, der sich damit nicht befasst, mag einiges von dem, was ich hier beschreibe, übertrieben erscheinen. Im Folgenden zeige ich eine Momentaufnahme des Upgrade-Prozesses meines Teams. Dieser umfasst zahlreiche Aufgaben, die ich in elf große Schritte unterteilt habe, die sich über drei Phasen vom Pre-Release zum Release und Post-Release ziehen.
Wenn ich mir das nur ansehe, bin ich schon fix und fertig. Dabei ist nicht einmal jeder Schritt abgebildet. Für Upgrade-Teams investieren viel Zeit und Mühen darauf, organisatorische Probleme beim Veränderungsmanagement zu lösen. Endnutzer sind frustriert über die zweimal jährlich stattfindenden Unterbrechungen ihrer Service-Deployments, die sie als wenig sinnvoll erachten.
Früher dachte ich, dass nur mein Team diese Probleme mit Upgrades hat, aber nachdem ich an Benutzergruppentreffen teilgenommen und Blogs gelesen hatte, wurde mir klar, dass Upgrades immer ein schmerzhafter Prozess sind. Einige Kunden beschwerten sich darüber, dass Upgrades mehr als acht Wochen dauerten, und murrten über die Produktivitätseinbußen für ihre Teams.
In einigen Fällen gehen Unternehmen sogar so weit, ihre alten ITSM-Systeme „neu zu starten“, um die Probleme mit Upgrades abzumildern. Zum Beispiel versuchen Kunden immer noch herauszufinden, wie sie die Next-Experience-Benutzeroberfläche von ServiceNow nutzen können, die im San Diego-Release vom März 2022 enthalten war. Einige Unternehmenskunden entscheiden sich dafür, die Funktionalität zu deaktivieren, bis sie die Auswirkungen auf ihre Nutzer abschätzen können.
Auf der Suche nach Abhilfe erkannte ich, dass es für dieses Problem Notlösungen gab – die Nutzung von Partnerservices für Upgrades, den Verzicht auf jegliche Systemmodifikationen, inkrementelle automatisierte Tests usw. Leider ist keine dieser Lösungen ein Allheilmittel und einige führen wieder an anderer Stelle zu Mehrarbeit.
Abhilfe finden – ein besserer Ansatz für ITSM-Systeme
So wie ich es sah, hatte ich zwei Möglichkeiten. Ich konnte entweder die inhärenten Herausforderungen unseres ITSM-Systems akzeptieren und den Antazida- und Ibuprofen-Vorrat in meiner Schreibtischschublade auffüllen oder nach einer robusteren, flexibleren Lösung suchen. In meiner Frustration las ich Analystenberichte auf Google und fragte Freunde aus dem ITSM-Bereich um Rat, bis ich schließlich bei Jira Service Management landete, der ITSM-Lösung von Atlassian.
Ehrlich gesagt war ich zunächst skeptisch, dass es unsere Probleme lösen könnte. Ich arbeite seit mehr Jahren mit Enterprise-ITSM-Systemen als mir lieb ist, und ich habe auch einige Jahre mit Jira Software gearbeitet. Deshalb war für mich erst einmal klar, dass Jira Service Management unsere Probleme nicht lösen würde.
Trotzdem probierte ich ein wenig mit der Assets-Funktion in Jira Service Management herum und es schien einfach zu sein, Daten zu konfigurieren und zu laden. Dann fing ich an, Projekte und Servicezuweisungsgruppen zu erstellen. Nach nur wenigen Stunden des Ausprobierens (und so manchem Blick in die Dokumentation) hatte ich einen funktionierenden Servicekatalog und einen Servicedesk aufgebaut, der IT-Assets und CIs sowie Funktionen für größere Vorfälle umfasste.
Jira Service Management bildet Elemente der Agile-Methodik ab wie „Starte dort, wo du bist“ und stellt sofort nutzbare ITIL-Praktiken bereit. Es war offensichtlich, dass die Lösung von Atlassian eher einen teamorientierten Ansatz verfolgte und weniger auf Tools ausgerichtet war.
Atlassians Ansatz bei Jira Service Management-Upgrades | Der Ansatz von Legacy-ITSM-Anbietern bei System-Upgrades |
|---|---|
| Agile und Wasserfall im Vergleich | |
| Atlassian folgt bei Jira Service Management-Upgrades der Agile-Methode, die Flexibilität, Zusammenarbeit und Effizienz unterstützt. | Der Ansatz von Legacy-ITSM-Anbietern bei System-Upgrades Legacy-ITSM-Anbieter folgen bei Upgrades einem Wasserfallansatz, der sich auf strukturierte, sequenzielle Releases konzentriert. |
| Eigenverwaltung vs. jährliche Pflichtupdates | |
| Jira Service Management-Kunden können ihre Veränderungsrate steuern, indem sie das Releaseprogramm für ihre Umgebung selbst festlegen. Continuous-Produkte erhalten Änderungen und Funktionen, sobald sie verfügbar sind. Bundle-Produkte erhalten Änderungen als Gruppe am zweiten Dienstag eines jeden Monats. | Der Ansatz von Legacy-ITSM-Anbietern bei System-Upgrades Legacy-ITSM-Anbieter geben in der Regel zweimal im Jahr Softwarereleases heraus, die neue Funktionen enthalten. |
| Laufende Funktionsreleases vs. Bugfixes bei Verfügbarkeit | |
| Der Ansatz von Atlassian bietet Kunden einen höheren Geschäftswert durch kürzere, vorhersehbare Releasezyklen, kleinere, hochwertigere Codesets und eine transparente, schnelle Bereitstellung von Funktionen. | Der Ansatz von Legacy-ITSM-Anbietern bei System-Upgrades Legacy-ITSM-Anbieter stellen je nach Bedarf/Verfügbarkeit Codepatches und Hotfixes bereit. Im Allgemeinen enthalten diese Patches und Hotfixes Bugfixes, aber keine neuen Funktionen. |
| Lose gekoppelte Architektur vs. eng gekoppelte Codesets | |
| Jira Service Management basiert auf einer lose gekoppelten Architektur, in der einzelne Komponenten unabhängig voneinander erstellt werden. Locker gekoppelte Anwendungen ermöglichen es Teams, Funktionen zu entwickeln, die getrennt voneinander bereitgestellt und skaliert werden, was eine effizientere Codebereitstellung/-aktualisierung ermöglicht. | Der Ansatz von Legacy-ITSM-Anbietern bei System-Upgrades Die Architekturen von Legacy-ITSM-Systemen sind eng miteinander verknüpft, sodass die Funktionen starr und voneinander abhängig sind. Wenn sich eine Komponente ändert, gibt es einen „Dominoeffekt“, der weitere Änderungen in der gesamten Anwendung nach sich zieht, was die Anzahl der Code-Änderungen und das Risiko insgesamt erhöht. |
| Echtes Cloudprodukt vs. isoliertes SaaS-Angebot | |
| Jira Service Management wurde für die Cloudplattform von Atlassian entwickelt, sodass Kunden dank integrierter Sicherheitsmerkmale, integrierter Compliance, mehrerer Instanzen (bis zu 150 pro Produkt) und vereinfachter Lizenzierung pro Benutzer problemlos skalieren können. | Der Ansatz von Legacy-ITSM-Anbietern bei System-Upgrades Legacy-ITSM-Systeme sind oft so konzipiert, dass sie lokal ausgeführt werden, und der Anbieter hostet die Anwendungen per Fernzugriff. Das sind keine echten Cloudlösungen und sie können nicht die gleichen Vorteile (Skalierbarkeit, Upgrades, Preise und Sicherheit) bieten wie ein echtes Cloudsystem. |
Ein besserer Ansatz für ITSM-Systemupgrades
Kommen wir zum Thema Upgrades. Atlassian plant die Weiterentwicklung seiner Technologien ein. Wenn also neue Funktionen verfügbar sind, kann die Funktionalität nahtlos in die Plattform und die Produkte integriert werden. Die Cloud-Roadmap von Atlassian ist öffentlich, sodass Kunden immer sehen können, was auf sie zukommt. Das cloudbasierte System von Jira Service Management bedeutet, dass für Kunden kontinuierlich oder nach Zeitplan neue Funktionen bereitstehen. Kunden können:
- die wöchentlichen Releasehinweise zu bevorstehenden Änderungen abonnieren
- eine isolierte Umgebung (auch bekannt als Sandbox) nutzen, um mit Funktionsänderungen zu experimentieren, bevor diese den Sprung in die Produktion schaffen
- ihre Änderungsrate steuern, indem sie das Releaseprogramm ihrer Produktionsumgebung selbst bestimmen (kontinuierlich oder im Paket)
- von kleinen, inkrementellen Updates profitieren, die für kontinuierliche Verbesserungen sorgen
Da Jira Service Management auf lose gekoppelten Codesets basiert, bietet es eine verbesserte Codeflexibilität/Wiederverwendbarkeit und effizientere Anwendungsupgrades.
Wir alle wollen die digitale Transformation beschleunigen, damit unsere Organisationen „intelligenter statt härter arbeiten“ können. Ich habe festgestellt, dass der agile, inkrementelle Upgrade-Ansatz von Jira Service Management es uns genauso ermöglicht, Releases zu validieren und mit Endbenutzern in Kontakt zu treten, aber in einer kontinuierlichen, schnelleren und unterbrechungsfreien Weise.
Wenn du die digitale Transformation in Angriff nimmst, empfehle ich, die Kernarchitektur und den Implementierungsansatz jeder Anwendung sowie die Gesamtbetriebskosten auf den Prüfstand zu stellen. Denke über die Geschäftsinitiativen nach, die du zu erreichen versuchst, und wähle ein System aus, das deinen Bedürfnissen entspricht und bei jeder Kundeninteraktion einen Mehrwert bietet.
Erfahre mehr über den Service-Management-Ansatz von Atlassian. ITSM-Lösungen von Atlassian: ein umfassender Leitfaden.
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
White Paper lesenLeitfaden: Was ist unter "Management von Serviceanfragen" zu verstehen?
Durch das Management von Serviceanfragen können IT-Teams Kundenanfragen schnell und einfach erfüllen. Hier erfährst du mehr über den Prozess an sich und über Best Practices.
Artikel lesen