Gute Einstellungen sind im ITSM nach wie vor verbreitet
(Originalartikel von Ivor Macfarlane, übersetzt von Amelie Yong (Mai 2021)):
Sagen Sie es weiter:
Seit einigen Jahren nehme ich regelmäßig an der Service Desk and IT Support Show (SITS) in London teil. Und auch dieses Jahr (2017) war es wieder eine geschäftige und unterhaltsame Veranstaltung.
Es begann mit einer Reise in die “falsche” Richtung – nach Norden – zu einem Workshop in Verbindung mit dem itSMF UK an der Universität Glasgow (es ist immer wieder eine Ehre, eingeladen zu werden, um an seiner alten Universität zu sprechen, auch wenn es nach dem Abschluss 42 Jahre dauert, bis man diese Einladung erhält).
Aus der Service Management Perspektive war dies für mich genauso wichtig wie die SITS, da das Publikum sich nicht nur aus Menschen aus dem IT-Bereich zusammensetzte, sondern Menschen aus allen Bereichen der Universitätsangebote anwesend waren – sogar der Universitätskaplan war dabei. Unternehmensweite Servicekultur ist das ausdrückliche Ziel, und dem Enthusiasmus und dem Grad der Beteiligung am Workshop nach zu urteilen, sind sie auf dem Weg, genau dies zu schaffen.
Zurück zur SITS
Ich flog zurück nach London zum traditionell vor der SITS stattfindenden “Networking-Event” mit alten und neuen Freunden. An dieser Stelle vielen Dank an Sophie Danby für ihre stets unvergleichliche Planungsfähigkeiten und an Service-Flow und Spoke für ihr großzügiges Sponsoring des Abends.
Bei der SITS selbst waren Toby Moore und ich Teil einer Zendesk-Initiative – der ITSM Genie Bar – als “Experten” an ihrem Stand und boten den Teilnehmer:innen die Möglichkeit, über jegliche Aspekte des IT-Service-Managements (ITSM) zu sprechen. Die Gespräche, die sich daraus ergaben, zeigten großartig das breite Spektrum von ITSM auf und waren auch sehr unterhaltsam. Das bringt mich zum Hauptzweck dieses Blogs – ich möchte dies anhand von vier besonderen Gesprächen veranschaulichen, die ich im Rahmen dieser ITSM-Genie-Bar-Initiative geführt habe.
Best Practice
Im ersten Gespräch, zusammen mit Toby, ging es um die Best Practice im Allgemeinen – die Beschaffenheit von Wert, die Kundenwahrnehmung und wie man gute Ideen durchsetzen kann. Wir haben Kochen als relevante Analogie verwendet. Wenn Menschen erkennen, dass sie bereits Best Practice als Konzept in ihrem täglichen Leben verwenden, können sie relevante Best Practice auch im Arbeitsumfeld leichter akzeptieren.
Wir machten Vorschläge zu Techniken wie Walkthroughs und Simulationen, um einen Anstoß für neue Sichtweisen zu geben. Ich erinnere mich an den letzten Gedanken dieses Gesprächs: Niemand sollte ein Essen zu Hause planen, ohne die Menschen zu fragen, was sie mögen oder zumindest zu wissen, was sie nicht mögen. Wir sollten auch keine neuen oder veränderten Services oder Verfahren ohne das entsprechende Wissen planen.
Change Management
Das zweite Gespräch drehte sich um das Change Management in einer sehr kleinen Organisation, in der das Testen nicht über die Development-/Operation-Grenze hinweg integriert ist. Wir haben darüber gesprochen, das Bewusstsein für den Betrieb (Operations) im gesamten Lebenszyklus zu stärken und den Service und nicht seine Komponenten zu testen. Insbesondere ging es darum, durch die Tests festzustellen, ob alle betrieblichen Anforderungen vor oder zumindest neben dem Testen der funktionalen Aspekte erfüllt waren. Wenn man sich über die Zeit im Klaren ist, die man aufbringen muss, wenn Dinge nach der Aufnahme in den Regelbetrieb schieflaufen, kann das ein guter Anlass dafür sein, sich darauf zu fokussieren, die Tests von Anfang an richtig zu machen. Zwei Dinge bleiben hierbei in Erinnerung: Eine Analogie, wie man die Jüngeren dazu bringt, gut zu ihrem älteren Selbst zu sein. Das ist so gemeint, dass ein ganzheitliches Testen während des Development damit gleichgesetzt werden kann, nicht zu rauchen, nicht zu viel zu trinken und fit zu bleiben. Auch wenn dies die Jugend (oder das Development) weniger lustig und spontan machen mag, ist dieser Verlust mehr als eine Belohnung in Form des glücklicheren Lifestyles des 40+ Jahre alten Körpers. Es lohnt sich auch, da durch umfangreicheres Design und Testen weniger Schwierigkeiten aufkommen und der Betrieb (Operations) reibungsloser wird. Zum anderen haben wir erkannt, dass wir über die informelle Einführung einiger Ideen sprachen, die aus DevOps bekannt sind – was den Ausdruck “einschleichende DevOps” zur Beschreibung dieser Ideen hervorrief.
Tool Provider
Als Nächstes fand ein umfassenderes Gespräch mit einem Team statt, das mit der Haltung seines Tool Provider unzufrieden war. Wir versuchten herauszufinden, welche Features in den heutigen Toolsets als normal und üblich angesehen werden. Es stellte sich heraus, dass ihr Provider heute fast universell verfügbare Features, wie z.B. Chat, nicht anbietet. Wir beschrieben ihre Situation schließlich als “Typisch 20. Jahrhundert”. Zusätzlich diskutierten wir über das Management von Lieferanten, Verträgen und Anbieterbeziehungen – alles darauf ausgerichtet, sich daran zu erinnern, dass Sie der/die Kund:in sind und das bekommen sollten, wofür Sie bezahlen, und nicht von Ihrem Lieferanten gesagt bekommen sollten, was zu tun ist. Alles in allem hat dieses spezielle Unternehmen beschlossen, nach mehr zu fragen und die Dinge etwas aufzumischen.
Servicekatalog
Das letzte Gespräch, das mir in Erinnerung bleibt, drehte sich um die Frage, wie man mit einem Servicekatalog anfängt: die anfänglichen Vorteile, die sich daraus ergeben, dass man weiß, was ein:e Kund:in von einem erwarten könnte. Und welche Services benötigt werden, um die externen Services zu ermöglichen.
Was die Servicedokumentation betraf, war dies im Grunde genommen eine „Greenfield site*“ und wie immer lautete der Rat: „Fangen Sie einfach an und entwickeln Sie Details so, wie Sie den Bedarf dafür erkennen.“ Tatsächlich war mein Rat, dass ein erster Entwurf eines geschäftsorientierten Servicekatalogs vielleicht mit einem Filzstift auf einem einzigen A4-Stück aufgeschrieben werden könnte. Lassen Sie die Details später kommen, aber finden Sie jetzt die Schlüsselservices.
Meine Gedanken
Zusammenfassend bin ich der Meinung, dass die ITSM Genie Bar eine starke Bekräftigung der guten Einstellungen ist, die im ITSM immer noch verbreitet sind. Es war großartig zu sehen, wie Zendesk das durch das Unterstützten der allgemeinen Diskussion um ITSM an ihrem Stand verstand, anstatt nur für ein Tool um seiner selbst zu werben, was sie meiner Meinung nach erwachsen und reif wirken ließ. Das kann auch ein attraktives Angebot für eine:n zukünftige:n Kund:in sein. Außerdem, was kann besser sein, als Menschen zu helfen?
Und schließlich eine Erwähnung des itSMF UK
Zusätzlich zu Zendesks Herangehen an einen Messestand, der Netzwerkveranstaltung vor der SITS und der Messe selbst, fühlte ich mich auf diese Weise auch dem itSMF UK zugeneigt. Zwischen meinen beiden halben Tagen bei Zendesk nahm ich an ihrem ITSM-Industriepreis-Abendessen teil, welches meiner Meinung nach sehr gut lief – und das nicht nur, weil sie mir einen Preis verliehen haben. Nach einigen Jahren des (von mir wahrgenommenen) Niedergangs scheint es, dass das itSMF und seine neue PSMF -Initiative wieder zu besserer Gesundheit zurückfinden – und zu einer weitreichenderen und relevanteren Zukunft. Und wenn man bedenkt, wie grundlegend das itSMF dazu beigetragen hat, unsere Industrie dorthin zu bringen, wo sie ist, dann ist das mit ziemlicher Sicherheit eine gute Sache.
Oh, und – ja, ich gebe es zu – es war ein Vergnügen und eine Ehre, den Paul-Rappaport-Preis des itSMF UK verliehen zu bekommen. Verdient oder nicht, ich habe den Moment genossen.
This article was originally published in English on ITSM.tools.
* braches/unentwickeltes Land