Symposium: Service Desk und ITSM 2023

EIN ERFAHRUNGSBERICHT AUS DEM SERVICEBETRIEB DER ASFINAG, DEM AUTOBAHNBETREIBER IN ÖSTERREICH

Was kann man von einem Fussballfeld lernen? Warum ist es wichtig, effizient zu arbeiten? Wie kann man die Kundenzufriedenheit nur durch Ändern der Grundeinstellung der IT Mitarbeitenden entscheidend verbessern? Anhand einer Customer Support Journey wird erklärt, welche Erfahrungen man damit im IT Betrieb der ASFINAG gemacht hat und wie daraus eine Erfolgsgeschichte wurde.

«Die IT» erfindet fast schon Inflationär «neue Begriffe und Rollen» so dass man sich die Frage stellt, was nun wirklich wichtig und was nur ein vorübergehender Hype ist. Die Rolle «Service Owner» erblickte vor gut 16 Jahren in ITIL® V3 die Welt und wurde im Service Design Buch recht gut beschrieben. Trotzdem finden wir nur in wenigen Service Organisationen die Rolle des Service Owner. Verbreiteter ist die Rolle Service Manager, jedoch ist das Verständnis dieser Rolle so unterschiedlich, dass sich die Aufgaben, Verantwortlichkeiten und Befugnissen von Service Manager nur selten vergleichen lassen. Doch, auch hier hilft ITIL® seit 16 Jahren weiter und wenn wir dies beherzigen, dann lernen wir die Wichtigkeit des Service Owner schätzen. Soviel vorweg, die Rolle Service Owner ist kein Hype.

Bei der Umsetzung von Ambitionen aus Business und IT besteht der Wunsch nach möglichst viel Freiheit für den Einsatz spezifischer Tools, Frameworks oder auch ganzer Softwarepakete. Leider steigt der Aufwand für Bereitstellung, Wartung und Betrieb mit jeder neuen Technologie grundsätzlich linear an.

Verschärft wird die Problematik, wenn IT-Systeme mit unterschiedlichen Technologien integriert werden müssen. Dann steigt der Aufwand schnell nicht mehr nur linear, sondern polynomial.

Technologievielfalt kann die Resilienz erhöhen, aber gleichzeitig erhöht sie auch die operativen Risiken. Und sie erhöht auch die Cyberrisiken, insbesondere unter einer Zero Trust Annahme, bei der davon ausgegangen wird, dass der Angreifer bereits innerhalb der Bank ist. ​

Mit dem Technol​​ogy Portfolio Management stellt die ZKB eine Balance aus Technologievielfalt und Restriktion her. D.h. das im Einsatz befindliche Technologieportfolio muss gesteuert und die Anzahl der parallel im Einsatz befindlichen Versionen derselben Technologie sollte möglichst klein gehalten werden.

Für die einen ist DevOps, wenn automatisiert entwickelt, getestet und deployed wird, für andere ist DevOps eine Kultur einer anderen Form von Zusammenarbeit und für die Dritten ist DevOps neuer Wein in alten Schläuchen: Ein neuer Begriff für etwas «was man schon immer so getan hat». Keine der oben aufgeführten Aussagen ist falsch; aber auch keine ganz richtig. DevOps erfordert eine «agile Kultur», das Beherrschen agiler Methoden, z. B. Scrum, den Bedarf oder gar die Notwendigkeit nach schnellen Releasezyklen und hoher Automatisation und eine anderes Verständnis des Begriffes «Betrieb».
DevOps ersetzt nicht etwa ITIL® sondern ergänzt dieses Framework. DevOps ist auch nichts völlig neues, sondern erblickte parallel zu ITIL® V3 vor 15 Jahren, im Jahre 2007 das Licht der Welt.
Lassen Sie sich aufzeigen, wann, wie und in welchem Kontext DevOps Sinn macht und welches die Schlüsselfaktoren sind, damit DevOps auch den angestrebten Nutzen stiftet und sowohl für das Unternehmen sowie auch für die Kunden den gewünschten Wert schafft. Um es vorweg zu nehmen – der absolute Schlüsselfaktor ist nach wie vor der Mensch – also Sie und ich.

In diesem Konferenzbeitrag erfahren Sie – gestützt auf umfassendes Erfahrungswissen des Referenten – wie ausgehend von durchgeführten Assessments eine Neupositionierung des Enterprise Data Management (kurz EDM) vorgenommen werden muss. Damit Organisation den Wert ihrer Daten erfolgreich schöpfen können, bedarf es kontextadäquater Daten- und KI-Strategien sowie differenzierter Handlungskonzepte. Hierfür können – ja müssen – Enterprise-, Data- und Solution-Architekten mit ihren Teams einen wesentlichen Beitrag leisten.
Ausgehend von den entwickelten Daten und KI-Strategien wird daher in dem Beitrag ein Data-centric Architekturkonzept präsentiert, aus dem heraus eine Roadmap zur Umsetzung einer schlagkräftigen EDM-Organisation entwickelt wird. Schließlich werden notwendige Changes aufgezeigt, wie mittels einer erneuerten Enterprise Data Governance neue Wege der Erbringung von Data-Products & Services (etwa bis hin zu Self Services) deutlich werden.
Folgende Arbeitsphasen, die auf dem Weg zu einer modernen datengetriebenen Organisation mit hoher Maturitätsstufe angegangen werden müssen, werden in dem Beitrag von Ernst Tiemeyer anschaulich und praxisnah erläutert:

• Der Trend zum Enterprise Data Management
• Erste Schritte auf dem Weg zur Data Driven Enterprise: Data Assessments, Positionierung, Capability und Anforderungsanalysen
• Handlungskonzept zur Priorisierung von EDM-Handlungsfeldern (Data Centric EAM, Data Mesh, Data Governance, Data Literacy)
• Roadmap mit Aktionsfeldern zur Umsetzung der EDM-Leitplanken
• Change der EDM-Organisation (Data Services, Data Culture)

Große Sprachmodelle der KI sorgen nicht erst seit ChatGPT für Diskussionen. Bereits GPT 3 zeigte, wie mächtig große Sprachmodelle sein können. Allerdings traten diese Systeme erst mit ChatGPT so richtig in das Licht der Öffentlichkeit. ChatGPT erreichte innerhalb kürzester Zeit ein Millionenpublikum, welches auf die unterschiedlichste Art und Weise mit der KI interagierte. ChatGPT steht auch nicht mehr alleine: Bard, Ernie oder LlaMA sind andere Namen in diesem Kontext.

Diese Systeme haben bereits Einfluss auf unseren Alltag – von Schülern über Studenten, die es als Werkzeug mit unterschiedlichem Erfolg nutzen, bis hin zu bereits ausgeschriebenen neuen Jobs wie z.B. „AI Prompter“.

Welche Leistungen können wir von diesen Systemen erwarten, und wo lauern Gefahren?