IT-Management Podcast | Für den Service-Management Nerd in Dir.

In dieser Podcast-Folge diskutieren Robert und Olaf die Herausforderungen im Managed-Service-Bereich, insbesondere die Komplexität der Abrechnung und die Volatilität der Dienstleistungen. Sie beleuchten die Notwendigkeit einer Prozessoptimierung im Service-Management, die Bedeutung von Laufzeiten und Kündigungsfristen sowie die verschiedenen Abrechnungsmodelle und Preisgestaltungen. Zudem wird die Hypothese aufgestellt, dass eine effiziente Datenübertragung zwischen Zulieferern und dem eigenen System die Abrechnungsprozesse vereinfachen könnte.

In dieser Episode diskutieren Robert Sieber und sein Gesprächspartner die Herausforderungen und Möglichkeiten im Bereich der Prozessoptimierung, vornehmlich im Einkauf und der Abrechnung von Managed Services. Sie beleuchten die Bedeutung von Datenqualität und Automatisierung, die Integration von ERP-Systemen und die Notwendigkeit einer aktiven Community zur Wissensweitergabe. Zudem wird der richtige Zeitpunkt für die Implementierung von Automatisierungslösungen thematisiert, sowie ein Ausblick auf zukünftige Entwicklungen, vornehmlich im Hinblick auf den Einsatz von KI.

Über die Jahre des Podcasts habe ich erfolgreich das Thema IT-Strategie umschifft. Es hat auch nie jemand danach gefragt. Bis jetzt. Nun kam Olaf Kaiser mit dem Thema und wir tauschen uns dazu in dieser Episode von Olaf und Robert aus. Auch wenn ich wahrscheinlich Olaf mit meinem „Strategie-Trauma“ genervt habe, ist doch ein sehr interessantes Gespräch herausgekommen. Gleich am Anfang erläutere ich dir, warum ich im Hinblick auf Strategie so skeptisch bin.

Ein falscher Klick, schlechter Quellcode in der selbst entwickelten Applikation oder ein mieses Sizing können rasch dazu führen, dass die Cloudkosten enorm steigen. Manchmal binnen kurzer Zeit. Binnen Minuten oder sogar Sekunden. Daher besteht die Notwendigkeit, dass sich dein Unternehmen mit den Kosten, die durch die Nutzung dynamischer Clouddienste anfallen, beschäftigt. Es reicht nicht mehr, dass sich das Controlling mit den IT-Kosten beschäftigt. Viel mehr Menschen in deiner IT dürfen sich dem Thema annehmen und entsprechend Expertise aufbauen.

Die Katastrophe der Titanic war vermeidbar. Sie war eine Aneinanderreihung von unglücklichen Entscheidungen, fehlenden Informationen sowie Glauben und nicht Wissen. In der heutigen Episode erfährst du vieles über die Titanic. Du erfährst, was wir in Hinblick auf ITSM davon lernen können. In dem Zusammenhang spreche ich mit Marc Schachteli über Business-Simulationen im Allgemeinen und sein Simulation Titanic ITSM im Besonderen.

Wie oft warst Du schon froh, dass das erste Gespräch mit einem neuen Anbieter vorbei ist? Endlich die Folienschlacht beendet. Vielleicht glaubst Du ja, dass der so toll ist, wie er sagt. Häufig hatten allerdings beide Seiten keinen Spaß.

Olaf Kaiser und ich sprechen heute genau über dieses Problem. Wir geben Dir Tipps und Anregungen, wie Du für ein besseres Erstgespräch sorgen kannst. Egal ob als Anbieter oder Kunde.

Der Hype ist groß - Large-Language-Modelle sollen die Arbeitswelt revolutionieren. Ganze Jobs wegfallen. Microsoft ist ein großer Spieler dabei. Mit dem Copilot sind sie sicher am weitesten, um die Möglichkeiten für eine breite Masse an Unternehmen nutzbar zu machen. Zusammen mit Alexander Eggers schauen wir uns an, was heute wirklich schon funktioniert. Wir sprechen über 6 ganz konkrete Einsatzfälle und was sie uns nutzen. Ich verrate Dir schon mal: "Zeit sparen" ist vielleicht nicht das wichtigste Argument.

Das heutige Gesprächsthema zwischen Olaf Kaiser und mir wird uns auch beim Workshop Financial Management beschäftigen. Es ist ebenfalls eines meiner Lieblingsthemen im Service-Management: Wir sprechen über Service-Requests, Request-Management und Self-Services.

Warum Lieblingsthema? Das Potential für Effizienzsteigerung, Kostensenkung und glücklichere Mitarbeitende ist in den meisten Unternehmungen einfach riesig. Die ersten großen Erfolge lassen sich ziemlich schnell realisieren.

Heute erzähle ich Dir eine Geschichte. Eine Geschichte von jemandem, der irgendwann die Nase voll hatte von der IT. Von der IT, wie wir sie heute kennen: technisch, wenig kundenorientiert, primär mit Betrieb beschäftigt und immer viel zu teuer. Ich nehme Dich mit auf seine einjährige Reise. Du erfährst, wie der Held der Geschichte Schritt für Schritt vorgegangen ist und welche grundlegenden Wandel er in nur einem Jahr erreichen konnte. Du erfährst zum Beispiel, wie der Held die Betriebsausgaben um 30 % senkt.

Ursprünglich geht es bei agilen Methoden darum, mit veränderten Umgebungsbedingungen schnell und gut klarzukommen. Im Prinzip genau das, was ich momentan erlebe. Ich könnte mich in mein Schneckenhaus zurückziehen, in der Hoffnung, dass das alles vorübergeht. Mache ich nicht. Ich schaue, wie ich die Situation adaptieren und ins bessere lenken kann. Ich glaube, genau darum geht es bei Agilität.

Was wir heute sehen, ist „Cargo-Kult“. Es wird nach Blaupause und Best Practices geschrien, damit man möglichst schnell xyz einführen kann. Möglichst wenig eigene Beschäftigung mit dem Thema. Fertig werden und gut.

Ich hoffe, dass diese Weihnachtsgeschichte Dir begreiflich macht, warum das nicht der richtige Weg ist.

Site Reliability Engineering (SRE) ist eine Disziplin, die das tiefe Verständnis von Softwareengineering mit einer ausgeprägten Fokussierung auf Zuverlässigkeit und Betriebsstabilität verbindet. Ursprünglich von Google entwickelt, zielt SRE darauf ab, die Lücke zwischen der Entwicklung und dem Betrieb von Software zu schließen, indem es Prinzipien des Engineerings auf Betriebsaufgaben anwendet. SRE-Teams sind dafür verantwortlich, Skalierbarkeit, Performance und Ausfallsicherheit von Services zu gewährleisten und dabei auch die schnelle Entwicklung und Bereitstellung neuer Features zu unterstützen. Sie nutzen eine Reihe von Methoden, wie Automatisierung und kontinuierliche Integration/Delivery, um manuelle Arbeit zu reduzieren und Fehlerquellen zu minimieren.

Genau über diese Methoden und SRE an sich spreche ich heute mit Alex Lichtenberger.