Close

ITSM voor razendsnelle teams

De zoektocht naar een oplossing voor de uitdagingen van het ITSM-systeemupgradeseizoen

Wat een producteigenaar heeft geleerd over alternatieven voor traditionele ITSM-systeemupgrades.

Ik was een producteigenaar voor een Scrum-team dat mogelijkheden ontwikkelde voor verschillende werkwijzen voor servicemanagement met behulp van een verouderd ITSM-systeem. Aan het einde van de laatste sprint van het kalenderjaar profiteerde mijn team van een innovatiesprint waarbij we konden leren en experimenteren met behulp van nieuwe functies. Ik heb deze innovatiesprint gebruikt om de nieuwe release van ons ITSM-systeem te bekijken. Op het eerste gezicht leken er heel veel nieuwe functies te zijn. Bij nader inzien was de nieuwe functionaliteit echter niet nuttig voor onze belanghebbenden en zou deze meer technische schulden als gevolg hebben.

Toen het eenmaal duidelijk was dat ons verouderde ITSM-systeem ingebouwde ondersteuningsproblemen had, realiseerde ik me dat ik twee mogelijkheden had. Ik kon deze problemen accepteren en mijn bureaulade vullen met antacida en ibuprofen, of ik kon op zoek gaan naar een robuustere, flexibelere oplossing.

Mijn hoofd begon te bonzen in afwachting van de vele vergaderingen met onze proceseigenaren en andere belanghebbenden. Alleen al de gedachte van het uitleggen van de inhoud van de nieuwe release, de verstoring van onze ontwikkelingsplanning en wat uiteindelijk slechts een kleinschalig nuttig gevolg zou zijn van al dit nieuwe werk, maakte me gestrest. Hoeveel functies we ook konden gebruiken, het vervelende proces en de verloren productiviteit tijdens het upgradeseizoen waren altijd hetzelfde.

De uitdagingen van het upgraden van een traditioneel ITSM-systeem

Voor degenen die hier nog niet mee te maken hebben gehad, lijkt een deel van wat ik beschrijf misschien overdreven. Daarom vind je hieronder een snapshot van het upgradeproces van mijn team. Dit omvatte vele taken die ik heb onderverdeeld in elf bredere stappen die zijn verdeeld over drie fasen, van de pre-release tot de release en de post-release.

Elf stappen voor het upgraden van een traditioneel ITSM-systeem

Ik word al moe als ik hier naar kijk. Dat terwijl het niet eens alles omvat. Teams die upgrades beheren, besteden aanzienlijk veel tijd en inspanning aan het oplossen van zaken op het gebied van organisatieverandermanagement. Eindgebruikers raken gefrustreerd door verstoringen van hun service-implementaties die twee keer per jaar plaatsvinden, die zij van weinig waarde achten.

Vroeger dacht ik dat de upgrade-problemen van mijn team geïsoleerd waren, maar nadat ik vergaderingen met gebruikersgroepen heb bijgewoond en blogs heb gelezen, besefte ik dat een lastig upgradeproces alomtegenwoordig is. Sommige klanten hadden klachten over upgrades die meer dan acht weken duurden en over productiviteitsverlies voor hun teams.

Soms ‘herstarten’ organisaties hun verouderde ITSM-systemen zelfs om upgrades te vergemakkelijken. Klanten proberen bijvoorbeeld nog steeds te ontdekken hoe ze Next Experience UI van ServiceNow, die bij de San Diego-release in maart 2022 was inbegrepen, kunnen gebruiken. Sommige enterprise-klanten kiezen ervoor om de functionaliteit uit te schakelen totdat ze de gevolgen voor hun gebruikers vast kunnen stellen.

Toen ik op zoek was naar een reddingsmiddel, zag ik dat er oplossingen waren voor dit probleem: gebruikmaken van partnerservices voor upgrades, systeemaanpassingen overslaan, bij stukjes en beetjes gebruikmaken van geautomatiseerd testmogelijkheden, enz. Helaas leken geen van deze opties geschikt genoeg, en zorgden sommige voor nog meer werk in een andere richting.

Op zoek naar hulp — een betere benadering van ITSM-systemen

Zoals ik het zag, had ik twee mogelijkheden. Ik zou ofwel de inherente uitdagingen van ons ITSM-systeem kunnen aangaan en mijn bureaulade kunnen vullen met antacida en ibuprofen, of op zoek gaan naar een robuustere, flexibelere oplossing. Gefrustreerd ging ik naar Google, las ik rapporten van analisten en raadpleegde ik vrienden op het gebied van ITSM. Dit bracht me bij Jira Service Management, de ITSM-oplossing van Atlassian.

Eerlijk gezegd was ik sceptisch dat het onze problemen zou kunnen oplossen. Ik werk al meer jaar met ITSM-systemen voor bedrijven dan me lief is, en ik heb ook een paar jaar voor Jira Software gewerkt. Dus ik was ervan overtuigd dat Jira Service Management onze problemen niet zou oplossen.

Ik heb een tijdje naar de Assets-functie in Jira Service Management gekeken en het leek me eenvoudig om gegevens te configureren en te laden. Daarna begon ik projecten en groepen voor serviceopdrachten aan te maken. Na slechts een paar uur configureren (en alle documentatie bekijken) had ik een werkende servicecatalogus en servicedesk ontwikkeld met IT-middelen en CI's en mogelijkheden voor grote incidenten.

Jira Service Management bevat elementen uit de Agile-methodologie, zoals 'begin waar je bent'. Ook biedt het kant-en-klare ITIL-praktijken. Het was duidelijk dat Atlassian een teamgerichte aanpak had gekozen in plaats van een op tools gerichte oplossing.

De aanpak van Atlassian voor upgrades van Jira Service Management

Benadering van systeemupgrades van verouderde ITSM-leveranciers

Agile versus waterval

Atlassian volgt de Agile-methodologie voor upgrades van Jira Service Management die flexibiliteit, samenwerking en efficiëntie optimaliseert.

Benadering van systeemupgrades van verouderde ITSM-leveranciers

Verouderde ITSM-leveranciers gebruiken een watervalbenadering voor upgrades, waarbij de nadruk ligt op gestructureerde, opeenvolgende releases.

Wijzigingen in je planning versus vereiste jaarlijkse updates

Klanten van Jira Service Management kunnen hun veranderingspercentage controleren door de gewenste releasetrack in te stellen voor hun omgeving. Continuous-producten ontvangen wijzigingen en functies zodra ze beschikbaar zijn. Gebundelde producten worden als groep gewijzigd op de tweede dinsdag van elke maand.

Benadering van systeemupgrades van verouderde ITSM-leveranciers

Verouderde ITSM-leveranciers leveren over het algemeen twee keer per jaar softwarereleases met nieuwe functies.

Lopende functie-releases versus beschikbare bugfixes

De aanpak van Atlassian biedt klanten meer bedrijfswaarde door kortere, voorspelbare releasecycli; kleinere codesets van hogere kwaliteit; en een transparantere, responsieve levering van functies.

Benadering van systeemupgrades van verouderde ITSM-leveranciers

Verouderde ITSM-leveranciers leveren codepatches en hotfixes die naar behoefte en beschikbaarheid voorkomen. Over het algemeen bevatten deze patches en hotfixes wel bugfixes, maar geen nieuwe functies.

Losjes gekoppelde architectuur versus nauw gekoppelde codesets

Jira Service Management is gebaseerd op een losjes gekoppelde architectuur waarbij afzonderlijke componenten onafhankelijk van elkaar worden gebouwd. Losjes gekoppelde toepassingen stellen teams in staat functies te ontwikkelen die onafhankelijk van elkaar geïmplementeerd en geschaald kunnen worden, wat zorgt voor een efficiëntere levering en upgrades van code.

Benadering van systeemupgrades van verouderde ITSM-leveranciers

Verouderde ITSM-systeemarchitecturen zijn nauw met elkaar verbonden, zodat functies star en onderling afhankelijk zijn. Wanneer een component verandert, ontstaat er een domino-effect van meer wijzigingen in de hele toepassing, waardoor algehele codewijzigingen en risico toenemen.

Een echt cloudproduct versus SaaS-aanbod in silo's

Jira Service Management is ontworpen en aangemaakt voor het cloudplatform van Atlassian, zodat klanten vol vertrouwen kunnen opschalen met ingebouwde beveiliging, ingebouwde naleving, meerdere installaties tot 150 per product en vereenvoudigde licenties per gebruiker.

Benadering van systeemupgrades van verouderde ITSM-leveranciers

Verouderde ITSM-systemen zijn vaak ontworpen om op locatie te draaien, en de leverancier host de applicaties gewoon op afstand. Dit zijn geen echte cloudoplossingen en bieden je niet dezelfde voordelen (schaalbaarheid, upgrades, prijzen en beveiliging) als een echt cloudsysteem.

Een gezondere aanpak voor upgrades van ITSM-systemen

Nu we het over de kwestie upgrades hebben: Atlassian is van plan om technologie te ontwikkelen, dus als er nieuwe mogelijkheden beschikbaar zijn, kan de functionaliteit naadloos geïntroduceerd worden in het platform en de producten. De cloud-roadmap van Atlassian is openbaar, zodat klanten altijd kunnen zien wat er gaat komen. Het cloudsysteem van Jira Service Management betekent dat klanten de functies continu of volgens een vast schema kunnen gebruiken. Klanten kunnen:

  • zich abonneren op de wekelijkse releasenotes voor de meest actuele informatie over toekomstige wijzigingen
  • een geïsoleerde omgeving aanmaken (ook bekend als Sandbox) om te experimenteren met wijzigingen in functies voordat deze naar productie gaan
  • hun tempo van verandering beheersen door het releasetraject van hun productieomgeving in te stellen (doorlopend en gebundeld)
  • profiteren van kleine, stapsgewijze updates die zorgen voor continue verbetering

Omdat Jira Service Management gebaseerd is op losjes gekoppelde codesets, biedt het verbeterde flexibiliteit/herbruikbaarheid van code en efficiëntere upgrades van toepassingen.

Het Atlassian-platform ondersteunt Jira Service Management door middel van analyses, automatisering, samenwerking, administratie, uitbreidbaarheid, gegevensbeheer en infrastructuur.

We willen allemaal de digitale transformatie versnellen zodat onze organisaties 'slimmer kunnen werken in plaats van harder'. Ik heb ontdekt dat de flexibele upgrade-aanpak van Jira Service Management voor stapsgewijze verandering en verbetering ons in staat stelt om releases te blijven valideren en in contact te komen met eindgebruikers — in een meer continu, sneller en ononderbroken tempo.

Als je aan een digitale transformatie begint, raad ik je aan om de kernarchitectuur en implementatieaanpak van elke toepassing te bekijken, evenals de total cost of ownership. Denk na over je bedrijfsinitiatieven die je probeert te bereiken en kies een systeem dat aan je behoeften voldoet en waarde toevoegt aan elke interactie met klanten.

Ontdek meer over hoe Atlassian servicemanagement afhandelt in De complete handleiding voor Atlassian voor ITSM.