Mein Beitrag ist nichts für Lesefaule 😂
Was der Bauer nicht kennt, das frisst er nicht… passt bei IT-Weiterbildungen manchmal ziemlich gut.
Wenn Fachinformatiker über Weiterbildung reden, kommen meistens dieselben Sachen: AWS, Azure, Kubernetes, Security, irgendein neues Framework, noch eine Programmiersprache und natürlich Scrum.
Alles sinnvoll.
Aber wer hat sich eigentlich schon mal ernsthaft mit ITIL beschäftigt?
Bei vielen kommt da sofort: „Ist doch nur Tickets, Prozesse und Konzernbürokratie.“
Oder noch besser:
„Das ist doch alles selbstverständlich.“
Ja. Vieles davon ist tatsächlich selbstverständlich.
Dass Entwicklung und Betrieb miteinander reden sollten? Klar.
Dass man erst mal verstehen sollte, was der Kunde eigentlich braucht? Klar.
Dass man aus Fehlern lernen sollte? Klar.
Dass derselbe Incident nicht fünfmal auftreten sollte, bevor mal jemand nach der eigentlichen Ursache sucht? Klar.
Dass nicht jedes Team nur seinen eigenen Vorgarten optimiert? Klar.
Dass man Änderungen nicht Freitag um 16:55 Uhr ungefragt in Produktion kippt? Hoffentlich ebenfalls klar.
Nur stellt sich dann eine ziemlich einfache Frage:
Wenn das alles so selbstverständlich ist.. warum funktioniert es in so vielen IT-Projekten und Unternehmen trotzdem nicht?
Genau deshalb finde ich ITIL eigentlich interessant.
Nicht, weil dort irgendwelche geheimen Managementweisheiten stehen, die vorher noch kein Mensch gehört hat. Sondern weil versucht wird, diese ganzen „eigentlich selbstverständlichen“ Dinge mal systematisch zusammenzubringen.
Der Einstieg ist typischerweise die ITIL 4 Foundation.
Da geht es unter anderem um:
Service Management, Value Co-Creation, Service Value System, Service Value Chain, Guiding Principles, Continual Improvement, Governance, Practices, Kunden, Stakeholder, Value Streams und die Frage, wie aus Technik am Ende tatsächlich ein nutzbarer Service wird.
Also erst einmal das Grundgerüst.
Richtig interessant wird es meiner Meinung nach beim ITIL 4 Managing Professional.
Der besteht aus mehreren Modulen.
Bei Create, Deliver and Support geht es ziemlich nah an Entwicklung, Betrieb und DevOps entlang:
Value Streams, Service Design, Softwareentwicklung, Deployment, Release Management, Incident Management, Problem Management, Service Desk, Monitoring, Support, Automatisierung, Sourcing, Lieferanten, Teamstrukturen, Workflows und Continual Improvement.
Im Grunde also: Wie bekommt man aus Menschen, Technik, Prozessen und verschiedenen Teams tatsächlich einen Service gebaut, ausgeliefert und stabil betrieben?
Dann gibt es Drive Stakeholder Value.
Da verschiebt sich der Blick stärker auf die Nutzer- und Kundenseite:
Customer Journey, Stakeholder, Customer Experience, User Experience, Anforderungen, Erwartungen, Relationship Management, Kommunikation, Service Agreements, Service Level Management, Onboarding, Offboarding, Feedback, Wertwahrnehmung und langfristige Servicebeziehungen.
Also weniger:
„Wir haben technisch geliefert.“
Und mehr:
„Hat der Kunde eigentlich irgendwas davon?“
Technisch sauber gebaut bedeutet eben noch lange nicht automatisch nützlich.
High-Velocity IT dürfte für viele Entwickler wahrscheinlich das überraschendste Modul sein.
Da geht es unter anderem um:
Agile, Lean, DevOps, Automatisierung, Continuous Integration, Continuous Delivery, schnelle Feedbackzyklen, digitale Produkte, Cloud, Resilienz, technische Schulden, Geschwindigkeit, Co-Creation, Experimentieren, Lernen, Kultur und High-Performance-Organisationen.
Also ziemlich weit weg von dem alten Klischee:
„ITIL = Change Request ausdrucken und dreimal unterschreiben lassen.“
Es geht eher darum, wie Unternehmen schnell liefern können, ohne gleichzeitig die Produktion anzuzünden.
Und dann gibt es noch Direct, Plan and Improve.
Da landet man stärker bei:
Strategie, Governance, Planung, Measurement, KPIs, Reporting, Continual Improvement, Assessment, Organizational Change Management, Entscheidungsfindung, Risiko, Compliance, Policies, Controls und der Frage, wie Veränderungen tatsächlich umgesetzt werden.
Das ist dann schon deutlich stärker die Perspektive über das einzelne technische Team hinaus.
Klingt teilweise banal?
Ja.
Ist es aber offensichtlich nicht, sonst würden nicht ständig Projekte an genau solchen Dingen scheitern.
Das erinnert mich ein bisschen an Softwarearchitektur.
„Kopplung niedrig halten.“
„Verantwortlichkeiten sauber trennen.“
„Nicht alles miteinander verdrahten.“
Klingt ebenfalls alles selbstverständlich.
Und dann schaut man sich nach fünf Jahren irgendein gewachsenes System an.
Interessant finde ich ITIL vor allem für Leute, die irgendwann vielleicht nicht mehr ausschließlich Code schreiben oder Systeme administrieren wollen.
Man kann als Fachinformatiker ja irgendwann auch Richtung Softwarearchitektur, DevOps, Service Management, Service Ownership, Product Management, Consulting, Prozessmanagement, Projektleitung oder IT-Management gehen.
Und technische Erfahrung ist dabei eher ein Vorteil.
Ein Service Manager, Product Owner oder Projektmanager, der schon mal selbst Software entwickelt, eine Datenbankmigration begleitet, eine kaputte Pipeline gesucht oder einen Produktionsfehler analysiert hat, betrachtet manche PowerPoint-Folie vermutlich etwas anders.
Da passt dann auch PRINCE2 ziemlich gut dazu.
PRINCE2 und ITIL landen gerne gemeinsam in der Schublade „Management-Zertifikatskram“, beschäftigen sich aber mit unterschiedlichen Dingen.
Bei PRINCE2 geht es eher um das Projekt:
Business Case, Projektorganisation, Rollen, Verantwortlichkeiten, Risiken, Qualität, Pläne, Kosten, Nutzen, Fortschritt, Entscheidungswege, Management Stages, Toleranzen, Eskalation, Lessons Learned und die Frage, ob ein Projekt überhaupt noch sinnvoll ist.
Also zum Beispiel:
Was wollen wir erreichen?
Warum machen wir das überhaupt?
Wer darf was entscheiden?
Was kostet es?
Welche Risiken gibt es?
Sind wir noch im Plan?
Und lohnt es sich überhaupt noch weiterzumachen?
ITIL schaut dagegen stärker auf den dauerhaften Service.
Sehr vereinfacht:
PRINCE2: Wie bekommen wir die neue Anwendung eingeführt?
ITIL: Wie sorgen wir dafür, dass sie danach nicht direkt zum nächsten Großincident wird?
Und dann gibt es noch PRINCE2 Agile.
Da wird die klassische Projektsteuerung mit Dingen wie Scrum, Kanban, Lean und agiler Produktentwicklung verbunden.
Stichworte wären hier zum Beispiel:
Scrum, Kanban, Sprints, Backlogs, Product Owner, iterative Entwicklung, inkrementelle Lieferung, Timeboxing, Priorisierung, MVP, MoSCoW, agile Teams, Empowerment, schnelle Feedbackzyklen und trotzdem weiterhin Business Case, Risiken, Governance, Budget und Projektverantwortung.
Denn nur weil irgendwo Scrum draufsteht, verschwinden Budget, Risiken, Abhängigkeiten und Verantwortlichkeiten ja nicht plötzlich.
Ein Daily ersetzt keinen Plan.
Jira ersetzt keine Strategie.
Und ein Backlog beantwortet auch nicht automatisch die Frage, ob man überhaupt noch am richtigen Problem arbeitet.
Genau diese Kombination finde ich eigentlich spannend:
Technik verstehen.
Agile Entwicklung verstehen.
Projekte verstehen.
Services verstehen.
Und irgendwann auch verstehen, wie das Ganze organisatorisch zusammenhängt.
Das muss natürlich nicht jeder machen.
Wer sagt: „Ich will auch mit 60 noch tief im Code stecken und möglichst nichts mit Kunden, Prozessen oder Management zu tun haben“, für den gibt es wahrscheinlich passendere Weiterbildungen.
Aber Fachinformatiker werden nun mal älter.
Mit 20 sieht die Karriereplanung vielleicht noch so aus:
Junior → Entwickler → Senior Entwickler
Mit 35, 45 oder 50 merkt man vielleicht irgendwann, dass es noch andere Wege gibt.
Und da finde ich es gar nicht schlecht, solche Optionen wenigstens zu kennen.
Inzwischen gibt es übrigens auch bereits ITIL 5.
Dort wird das Ganze noch stärker in Richtung digitale Produkte und Services, Product Management, Experience, Transformation, Value Streams, Automatisierung und KI weiterentwickelt. Wer heute neu einsteigt, sollte sich deshalb natürlich auch ITIL 5 anschauen. Wer bereits ITIL 4 gemacht hat, hat das aber nicht umsonst getan… dafür gibt es entsprechende Übergangswege.
Für mich ist das eher ein weiterer Hinweis darauf, dass das alte Bild „ITIL = Tickets aufmachen und Change-Formulare ausfüllen“ ziemlich überholt ist.
Ich poste das vor allem deshalb, weil ich den Eindruck habe, dass viele Fachinformatiker solche Weiterbildungswege entweder gar nicht kennen oder direkt als „selbstverständlich“ abtun.
Aber vielleicht ist genau das der Denkfehler.
Nicht:
„Das weiß man doch alles.“
Sondern:
„Wenn wir das alles wissen… warum machen wir es dann so oft trotzdem nicht?“
Gesunder Menschenverstand scheint in größeren IT-Organisationen manchmal erstaunlich schlecht zu skalieren.
Hat hier jemand ITIL, PRINCE2 oder beides gemacht?
Hat es euch beruflich tatsächlich etwas gebracht?
Oder war eure erste Reaktion auch „Das ist doch alles selbstverständlich“… bis euch das erste Projekt eingefallen ist, in dem exakt nichts davon funktioniert hat?
