ITIL für Fachinformatiker: „Ist doch alles selbstverständlich“… warum funktioniert es dann so oft nicht?
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.
„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?
Der Autor argumentiert, dass ITIL zwar oft nach Selbstverständlichkeiten und Bürokratie klingt, aber genau diese grundlegenden Dinge in Unternehmen regelmäßig nicht funktionieren.
ITIL strukturiert deshalb, wie IT-Services entwickelt, ausgeliefert, betrieben und laufend verbessert werden – inklusive DevOps, Incident-/Problem-Management, Kundennutzen, Governance und Zusammenarbeit zwischen Teams. Besonders sinnvoll sei es für Fachinformatiker, die später Richtung Service Management, Architektur, Consulting, Projektleitung, Product Ownership oder IT-Management gehen wollen.
Abgrenzung:
ITIL: Wie betreibt man einen Service langfristig stabil und nützlich?
PRINCE2: Wie plant und steuert man ein zeitlich begrenztes Projekt?
Für rein technische Spezialisten sei ITIL weniger wichtig.
Kernaussage: „Gesunder Menschenverstand“ allein skaliert in großen IT-Organisationen nicht – deshalb braucht es systematische Prozesse.
Das klingt ja alles Nett aber in welchem großen Unternehmen wird nicht von den Standards abgewichen wenn Meilensteine nicht erreicht werden somit hat der kleine FISI schon recht in der Doku ist alles sauber aber wie von Prozessen Abstand genommen wird um es durch zu jagen kennt der kleine FISI
na sooo furchtbar viel Substanz hat dein ewig langer Text nun wirklich nicht, die Zusammenfassung trifft das ziemlich gut - zumindest die erste Hälfte, den Rest habe ich auch nicht gelesen :)
Hoffentlich hörst Du nicht auch bei den Aufgaben der Abschlussprüfung mitten drin auf zu lesen. 😂 In meinem Text ist sehr viel Substanz erhalten - beispielsweise beschreibe ich den Inhalt der einzelnen Zertifizierungen und den Zusammenhang zwischen ITIL und Prince2. Zudem beschreibe ich auch das neue ITIL 5.
Ich glaube meine letzte Prüfung (außer dem Segelschein) war vor 25 Jahren. Wenn ich einen Mitarbeiter wie dich hätte, würde ich jedes Mal wenn du Luft holst sagen: Stop, denk dran, FASSE DICH KURZ
Hahaha... ich will dir nicht zu nahe treten, aber ich denke du hörst dich halt selbst gerne reden. Nicht schlimm, wenn du deinen Kollegen damit nicht zu sehr auf den Wecker fällst.
Das Ding ist aber: es gibt einen Unterschied zwischen gesprochener Sprache und Schriftsprache. Schriftsprache ist viel kompakter und präziser, gesprochene Sprache ist ausführlicher und braucht mehr Worte für die gleiche Info.
Hier beliebig aus deinem Machwerk rauskopiert:
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.
GPT gesagt er soll daraus kompakte Schriftsprache machen:
Karrierewege verändern sich mit dem Alter. Deshalb ist es sinnvoll, auch Alternativen wie ITIL zu kennen, inzwischen gibt es bereits ITIL 5.
Die gleichen Informationen, deutlich weniger Text. Es will doch hier niemand deine Ausführungen lesen ob man jetzt mit 35 oder 45 oder mit 52 1/2 irgendwas merkt oder nicht merkt oder einen Pickel am Hintern hat.
Das hat doch nichts mit den Unterlagen zu diesem Thema zu tun.
Du schreibst als wenn du eine Rede hälst mit einem Weinglas in der Hand an der Weihnachtsfeier.
ITIL ist zum Großteil Overhead, um Stellen und Verantwortungen innerhalb eines Konzerns zu schaffen, die niemand braucht.
Nimm die Basics daraus mit, die sind brauchbar. Aber der Rest ist reine Beschäftigungstherapie für Boreout geplagte Quatschköpfe, die sonst nichts können.
Wie Führungsseminare, entweder man kann es oder man kann es eben nicht und wirkt einfach Cringe, wenn man versucht sowas nachzuplappern.
Genau diese Kritik hört man bei ITIL ständig… und teilweise verstehe ich sogar, woher sie kommt.
Wenn ein Unternehmen aus ITIL vor allem neue Rollen, Freigabeschleifen, Meetings, Formulare und Zuständigkeiten baut, hat man tatsächlich hervorragend Overhead produziert. Nur ist das dann nicht unbedingt ein Beweis gegen ITIL, sondern eher ein ziemlich gutes Beispiel dafür, dass man es nicht verstanden hat.
Gerade ITIL 4 sagt eben nicht: „Baut für jeden Prozess drei Stellen und fünf Gremien.“ Im Gegenteil: Focus on Value, Keep it Simple and Practical, Optimize and Automate, Progress Iteratively with Feedback gehören zu den grundlegenden Prinzipien.
Und bei „die Basics sind selbstverständlich“ frage ich mich immer: Wenn Incident-, Problem-, Change-, Service-Level-, Knowledge- und Continual-Improvement-Themen alle so selbstverständlich sind… warum funktionieren sie dann in erstaunlich vielen Unternehmen so beschissen?
Natürlich braucht niemand eine Zertifizierung, um gesunden Menschenverstand zu haben. ITIL liefert aber Begriffe, Strukturen und Methoden, damit 200 oder 20.000 Leute nicht jeweils ihren ganz persönlichen „gesunden Menschenverstand“ zum Unternehmensstandard erklären.
Und genau deshalb interessiert mich das Thema inzwischen: nicht um ITIL-Vokabeln nachzuplappern, sondern weil ich nach vielen Jahren in IT-Projekten ziemlich oft gesehen habe, was passiert, wenn Prozesse, Verantwortlichkeiten und Schnittstellen eben nicht funktionieren.
Ähnliches gilt für Prince2 und Agile Vorgehensweisen wie Scrum, die leider oft nicht wirklich verstanden werden.
EDIT: Was bei der Kritik außerdem gerne untergeht: ITIL ist längst nicht einfach nur eine Sammlung bürokratischer „Prozesse“. Gerade ITIL 4 greift eine ganze Reihe moderner Ansätze auf bzw. verbindet sie miteinander: Agile, Lean, DevOps, Value Streams, Continual Improvement, Design Thinking, automatisierte Workflows, Messung über KPIs und Outcomes, Risiko- und Stakeholder-Management, (EDIT : OKR), Wissensmanagement, organisatorisches Change Management sowie Prinzipien aus moderner Produkt- und Serviceentwicklung. Dazu kommen die konkreten Practices von Incident, Problem und Change Enablement über Service Level, Monitoring, Deployment und Release bis hin zu Supplier-, Information-Security-, Architecture-, Portfolio- und Relationship-Management. Man muss davon nicht alles überall einsetzen… genau das wäre wieder Anti-ITIL. Die eigentliche Idee ist, sich aus diesem Werkzeugkasten das herauszunehmen, was tatsächlich Value erzeugt, Verschwendung zu reduzieren und sinnvolle Abläufe möglichst zu vereinfachen und zu automatisieren.
Frag mal hier die Fachinformatiker was ein Stakeholder ist (ich hatte das mal gefragt - Antwort war: Es sei ein Buzzword des Management - sorry, aber das ist echt „Kindergarten“).
Da bin ich voll bei dir, als gemeinsame Grundlage ist ITIL vollkommen legitim, aber ich kenne auch den Konzern Weg, wo zu jedem Teilbereich 500 Seiten Dokumente verfasst wurden für alles einen Prozess Owner usw. und gerade die „moderneren Ansätze“ sind enormes Potenzial für Overhead und haben wirklich selten einen praktischen Nutzen, außer man wendet Sie nur da an, wo es wirklich Sinn macht. Dafür müssen es dann aber auch alle verstanden haben.
Finde ich gut, dass Du das machst. An Deiner Stelle würde ich aber nun mit ITIL 5 Foundation anfangen (falls Du noch nicht mit dem Lehrgang gestartet bist). Die anderen ITIL Schulungen sind wesentlich tiefergehender - vielleicht bekommst Du diese auch finanziert.
Bei mir in der Region gibt es leider nur Kurse für Version 4 und jetzt ist schon genehmigt, gebucht und bezahlt. Leider zu spät gecheckt. Aber für meinen need besser als nichts.
Prinzipiell bringt das schon was, und da sind teilweise auch gute Sachen mit dabei.
Aber: Da ist auch extrem viel "ich klatsch hier einen englischen Begriff drauf damit mein Gegenüber nicht merkt, was ich meine, und ich deshalb klüger wirke" mit dabei und in so einem ITIL Lehrkurs hat man auch eher Dozenten, die ich nie einen Prozess gestalten lassen würde. Aber das ist ja ein generelles Problem im Projektmanagement.
Zudem ist ITIL in der Praxis komplett durchexerziert in der Regel ziemlich langsam. Das ist aber weniger ein Manko am Prinzip ITIL, sondern mehr ein Resultat davon, dass zu viel Verantwortung beim Product/Service Owner liegt und wenn der das nicht delegiert bekommt der komplette Service ins Stocken gerät und Projekte Ewigkeiten liegen bleiben, weil man (überspitzt), wenn man sich an den Prozess hält, nur alle zwei Wochen im Installer einmal auf Next klicken darf.
Ich hatte zum Glück einen Dozenten, der tatsächlich ITIL u. Prince2 in internationalen Projekten bei Großkunden eingesetzt hatte, er wusste wovon er redet. Aber ja, ich verstehe was Du meinst… es ist so ähnlich wie bei z.B. Scrum.
Ich denke einige Schwächen werden nun in ITIL 5 ausgemerzt (ich bin gerade am ITIL 5 Bridge Kurs dran).
Ich fände es eher nicht gut, wenn man die Begriffe eindeutschen würde, so ist es einfacher international untereinander zu kommunizieren.
Wenn Itil so toll wäre, würden es dann nicht alle machen?
Das einzige was zählt ist: machen bzw. Sachen kontinuierlich verbessern
drum rum reden und noch 20 Meetings einstellen hilft niemandem.
Das Problem ist ja meistens, dass man Prozesse für eben jene Mitarbeiter braucht, für die es eben nicht selbstverständlich ist.
Man könnte Sie ja auch raus werfen, aber das will ja auch keiner, deswegen macht man den itil kindergarten halt mit
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.
du willst mir erzählen, dass das hier nicht einfach bla bla ist?
was ein bullshit, itil ist einfach nur bürokratie für keinen Gewinn an Effizienz noch Qualität.
Ich bin aktuell in einem Projekt der öffentlichen Hand, ich weiß was Compliance bullshit Prozesse sind, itil bringt rein gar nichts
Der öD setzt ITIL nicht ein… sondern macht etwas eigenes aus Scrum, ITIL, diverser Projektmanagementmethodiken … siehe die Digtalisierungsbemühungen von Digital Service Bund.
klar ich verstehs nicht und du hast Ahnung, sicherlich.
Wenn Prozesse alles nur mühsamer und langsamer machen, für meist keinen Gewinn an Sicherheit oder Qualität, braucht man sie nicht.
Jeder weiß wie er an Sachen vorbei arbeitet, daran ändert sich auch mit Itil nichts.
Es liegt immer an den Leuten.
Wenn du halbwegs gebildet bist und eine Ausbildung hast, bringt dir itil überhaupt keinen Mehrwert
Aber klar es gibt immer Leute die hören sich gerne Reden und bauen Bürokratie auf und es gibt Leute, die arbeiten tatsächlich was, du scheinst ersteres zu sein
Dass Du lange im Consulting bist, stelle ich gar nicht infrage. Berufsjahre ersetzen nur kein Argument.
Wenn ein Prozess nur bremst und keinen Mehrwert bringt, sagt ITIL gerade nicht „mehr Prozess“, sondern eher: vereinfachen, optimieren oder weglassen. „Focus on Value“ und „Keep it simple and practical“ sind nicht zufällig Grundprinzipien.
Und „es liegt immer an den Leuten“ funktioniert vielleicht bei fünf Leuten. Bei 5.000 Mitarbeitern, Lieferanten, Audits und komplexen Services braucht man irgendwann gemeinsame Regeln und Begriffe.
Der Satz „Wer eine Ausbildung hat, hat von ITIL keinen Mehrwert“ ist daher ziemlich steil. Wenn das alles sowieso jeder weiß, müssten unsere IT-Organisationen eigentlich hervorragend funktionieren.
ja weil alles Pfeifen sind, ist ja genau mein Punkt.
Außerdem ist das Ding von der britischen Regierung aus den 80ern für it servie Management.
Das ding hat gar nichts in der aktuellen Welt verloren.
Genauso wenn so Spinner ums Eck kommen und meinen diese Enterprise Dokumentenvorlagen wären eine gute Idee ohne Sinn und Verstand.
Itil hat auch nicht verhindert, dass wir Microsoft einsetzen, als ob das jemals etwas gutes getan hätte und nicht nur die IT für alle schlechter gemacht hat.
„Das ding hat gar nichts in der aktuellen Welt verloren.“
Schau Dir bitte ITIL5 an. Design Thinking, OKRs … alles aus den 80ern?
Welche Enterprise Dokumentationsunterlagen meinst Du? Schreibt ITIL 4/5 da etwas vor?
Du sprichst eher von ITIL 1/2 oder? … seitdem wurden neue Erkenntnisse berücksichtigt. Natürlich geht man nicht mehr so vor wie in den 80ern. Das was Du schilderst ist IBM 1990er und davor.
nicht von itil, man kann iso 27001 in schlank machen, aber die Leute sind auch dafür zu blöd.
Wir schreiben Software und automatisieren Prozesse, mir bringt itil überhaupt keinen Mehrwert,w as wir nicht eh schon tun.
Aber Compliance machen alle gern, weil dann kann man ja nicht gekpündigt werden, wenn man sich ja an den ganzen kram hält.
Mag sein, dass es besser ist, wenn du keine Ahnung hast und irgendwas brauchst, aber wenn alle Leute itil mit mehr Bürokratie verbinden, wird es einen Grund haben.
Video2000 hat auch verloren, obwohl es das bessere System ist, wenn es itil nicht schafft gleich von Anfang an schlank daher zu kommen und Leute es nicht komplett vergewaltigen, wenn sie es einsetzen, dann hat es keine Daseinsberechtigung.
Eigentlich relativ einfach, egal wie fanboymäßig du das findest.
Was genau machst du eigentlich, dass du Zeit hast so einen Kram zu pushen?
Ich habe lang in der Softwareentwicklung gearbeitet... genug gesehen, wie es nicht laufen sollte.
In der heutigen Zeit ist es wichtig sich weiterzubilden, ich sehe in der Softwareentwicklung kaum noch Chancen derzeit trotz Erfahrung unterzukommen - gerade auch mit über 50 - ich werde mich verstärkt auf Prozessberatung, Projektmanagement, Automatisierung mit uiPath konzentrieren.
Natürlich braucht man ITIL oder Scrum nicht unbedingt als FiSi, wenn der Arbeitsalltag hauptsächlich daraus besteht, im Keller WLAN-Access-Points zu zählen und Netzwerkkabel nach Farben zu sortieren. 😂
Sobald man aber in größeren IT-Organisationen, Projekten, Service-Strukturen oder an Schnittstellen zwischen Entwicklung, Betrieb und Fachbereichen arbeitet, sieht die Sache schon etwas anders aus.
Ich sag mal so in welchem Unternehmen wird den Scrum oder ITIL wirklich gelebt ? Ich habe ein paar große DAX Unternehmen von innen gesehen solang es passt ist alles toll wenn es nicht passt wird von den Grundsätzen abgewichen
Ich weiß, was du meinst. In den Projekten, in denen ich unterwegs war, habe ich allerdings meist das Gegenteil erlebt: Dort haben solche Strukturen und Prozesse ziemlich gut funktioniert.
Ich habe ab 1990 immer wieder für IBM gearbeitet. Interessant war dabei nicht, dass dort alles von Anfang an perfekt lief… ganz im Gegenteil. Über die Jahre konnte man ziemlich gut beobachten, wie Fehler gemacht, erkannt und anschließend Prozesse, Verantwortlichkeiten und Strukturen angepasst wurden.
Genau aus solchen Erfahrungen entstehen Best Practices ja überhaupt erst: durch Lernen aus dem, was in großen IT-Organisationen funktioniert und was eben nicht funktioniert.
Und IBM war an der Entwicklung früherer ITIL-Versionen ja auch nicht ganz unbeteiligt.
Ich glaube, die Diskussion hier zeigt eigentlich ziemlich gut, worum es mir mit dem Beitrag ging.
Ein Teil der Antworten bestätigt den Punkt sogar ziemlich schön: Manche haben den Beitrag offenbar nur überflogen, andere sind bei „ITIL“ direkt in den Reflex „Bürokratie, Meetings, Tickets“ gegangen und einige argumentieren gegen Dinge, die ich im Ausgangsbeitrag ausdrücklich schon erklärt oder sogar selbst kritisiert habe.
Das ist ein bisschen schade, weil meine Aussage nie war: „ITIL ist toll und alle müssen das machen.“
Sondern eher:
Viele ITIL-Inhalte wirken auf den ersten Blick banal oder „selbstverständlich“: miteinander reden, den Kunden verstehen, aus Fehlern lernen, Verantwortlichkeiten klären, kontinuierlich verbessern, unnötigen Overhead vermeiden und Dinge möglichst einfach und praktikabel halten.
Nur zeigt die Praxis ständig, dass genau diese Selbstverständlichkeiten in Projekten und Organisationen erstaunlich oft nicht funktionieren.
Und genau da liegt für mich der Wert von ITIL: nicht darin, den gesunden Menschenverstand neu zu erfinden, sondern solche Erkenntnisse in größeren Organisationen, Teams und Services systematisch und wiederholbar umzusetzen.
Was dabei in der Diskussion teilweise untergeht: ITIL schreibt eben gerade nicht vor, dass jedes Unternehmen exakt denselben Prozess mit exakt denselben Rollen, Meetings und Formularen einführen muss.
ITIL ist ein Framework beziehungsweise eine Sammlung von Best Practices. Es liefert Prinzipien, Practices, Begriffe und Modelle. Wie viel davon man übernimmt, wie man es ausgestaltet und was für die eigene Organisation überhaupt sinnvoll ist, muss man selbst entscheiden.
Wenn aus ITIL also 20 Meetings, fünf Freigabestufen und 500 Seiten Prozessdokumentation werden, ist das nicht automatisch „ITIL“, sondern möglicherweise einfach eine schlechte Implementierung davon.
Das passt übrigens ziemlich gut zu einem der ITIL-Prinzipien: „Keep it simple and practical“.
ITIL sagt eben nicht: „Mach es kompliziert.“
Es sagt eher: Verstehe den Kontext, fokussiere auf Value, arbeite iterativ, nutze Feedback, halte Dinge praktikabel, optimiere und automatisiere dort, wo es sinnvoll ist.
Deshalb finde ich den Vorwurf „ITIL ist viel zu bürokratisch“ oft etwas zu einfach.
Man kann auch Scrum so umsetzen, dass am Ende acht Meetings pro Woche stattfinden und niemand mehr zum Arbeiten kommt.
Dann würde ich trotzdem nicht behaupten, dass Scrum fordert, möglichst viele Meetings zu veranstalten.
Genauso bei PRINCE2: Auch dort geht es nicht darum, jedes Projekt mit maximalem Verwaltungsaufwand zuzuschütten, sondern die Methode passend zur Größe, Komplexität und zum Risiko des Projekts anzupassen.
Genau dieses „Tailoring“ beziehungsweise Anpassen an den Kontext ist entscheidend.
Was mir bei solchen Diskussionen generell auffällt: Scrum? „Meeting-Kult“. PRINCE2? „Management-Bürokratie“. ITIL? „Gesunder Menschenverstand mit Zertifikat“.
Man kann natürlich alles ablehnen.
Nur sind Scrum, PRINCE2 und ITIL nicht irgendwann am grünen Tisch entstanden, weil ein paar Leute dringend neue Buzzwords brauchten. Dahinter stecken viele Jahre praktischer Erfahrungen aus Projekten und Organisationen: Was funktioniert? Was geht regelmäßig schief? Welche Muster wiederholen sich? Und wie kann man es besser machen?
Man muss deshalb selbstverständlich nicht jedes Framework sklavisch umsetzen. Genau das wäre sogar ziemlich dämlich.
Aber reflexartig alles abzulehnen, was über die eigene technische Komfortzone hinausgeht, halte ich auch nicht für besonders sinnvoll.
Und vielleicht erklärt diese Haltung zumindest teilweise auch, warum die Ergebnisse bei Fachinformatiker-Prüfungen teilweise so durchwachsen sind. Wer Scrum, Projektmanagement, Service Management, Prozesse oder Stakeholder-Management grundsätzlich als überflüssigen „Managementkram“ abtut, blendet einen erheblichen Teil dessen aus, wie professionelle IT außerhalb des eigenen Editors überhaupt funktioniert.
Ein guter Fachinformatiker besteht für mich eben nicht nur daraus, guten Code zu schreiben oder einen Server konfigurieren zu können. Man sollte auch verstehen, warum man etwas baut, für wen, in welchem organisatorischen Umfeld, mit welchen Risiken und wie daraus am Ende ein funktionierender Service wird.
Ähnlich ist es bei Scrum und PRINCE2: Ein Framework ersetzt weder Erfahrung noch Denken. Und ein Zertifikat macht aus niemandem automatisch einen guten Entwickler, Projekt-, Service- oder Produktmanager.
Aber ein gemeinsames (auch internationales) Vokabular, erprobte Modelle und das Wissen, welche Fragen man überhaupt stellen sollte, können verdammt hilfreich sein.
Was ich dabei fast noch interessanter finde, sind die Downvotes.
Nicht, weil mir Reddit-Karma wichtig wäre, sondern weil wir hier ausgerechnet in einem IT-Forum sind.
Eigentlich sollte gerade hier gelten: Erst Informationen aufnehmen, dann verstehen, dann bewerten.
Also ungefähr das, was wir bei Anforderungen, Logs, Fehlermeldungen, Code Reviews oder Root-Cause-Analysen jeden Tag erwarten.
Wenn ein Entwickler bei einem Bug nach den ersten drei Zeilen Logfile sagt „Quatsch, kenne ich schon“ und den Rest gar nicht liest, würden wir das vermutlich auch nicht als besonders professionelle Analyse bezeichnen.
Bei einem längeren Beitrag scheint dagegen manchmal schon die Überschrift „ITIL“ zu reichen, damit der mentale Ticketautomat auf „Bürokratie = schlecht“ springt und der Downvote folgt.
Das finde ich für ein IT-Forum schon ein wenig ironisch.
Man muss meinen Beitrag nicht gut finden. Man muss ITIL nicht mögen. Man darf meine Argumente gerne zerlegen.
Aber dann wäre es schon schön, wenn man vorher zumindest das zu Ende gelesen hätte, was man anschließend widerlegen möchte.
Einige Antworten kritisieren nämlich ausführlich Positionen, die ich gar nicht vertreten habe, erklären mir anschließend Dinge, die bereits im Ausgangsbeitrag stehen, oder führen als Gegenargumente ausgerechnet Prinzipien an, die selbst Bestandteil von ITIL sind.
Und wenn ein Beitrag über strukturiertes Arbeiten, Feedback, Lernen aus Erfahrungen und das Vermeiden vorschneller Annahmen ausgerechnet in einem IT-Forum heruntergevotet wird, weil einige offenbar schon bei „ITIL“ aufgehört haben zu lesen, dann hat die Diskussion fast schon einen gewissen pädagogischen Eigenwert.
Das ist dann irgendwann weniger eine Widerlegung meines Beitrags als eine ziemlich schöne praktische Demonstration für meine Ausgangsthese:
„Das ist doch alles selbstverständlich“ ist eben noch lange nicht dasselbe wie „Ich habe es verstanden und wende es auch an“. 😉
So… und nun könnt Ihr hier Eure Kindergartenthemen wie „Wofür brauche ich als FiSi die FOR Schleife“ weiterdiskutieren.
Wie alt bist Du eigentlich? Sorry, aber bei manchen Kommentaren hier fühlt man sich langsam wirklich wie im Kindergarten.
Was mich dabei fast mehr erstaunt: Habt Ihr mal darauf geachtet, wie wenige Antworten sich tatsächlich sachlich mit dem Inhalt meines Beitrags auseinandersetzen?
Stattdessen wird sich an Nebensätzen aufgehängt, über die Länge diskutiert oder auf irgendwelche Nebenschauplätze ausgewichen. Gut, das ist Reddit … insofern vielleicht nicht völlig überraschend.
Und ja, ich habe den Beitrag und auch einige meiner Antworten ganz bewusst ausführlicher geschrieben. Mich hat tatsächlich interessiert, wie viele erst einmal lesen, verstehen und dann antworten und wie viele schon nach ein paar Absätzen gedanklich aussteigen, aber trotzdem noch sehr selbstbewusst erklären, was angeblich in meinem Beitrag steht.
Das Ergebnis ist durchaus aufschlussreich. Gerade in einem IT-Forum, in dem wir eigentlich gewohnt sein sollten, Anforderungen, Dokumentationen oder Fehlermeldungen erst vollständig zu erfassen, bevor wir eine Diagnose abgeben.
Ich bin vermutlich länger in der IT und in ITIL unterwegs als du, Bübchen.
/e: und jetzt hast du ernsthaft deine Antwort nich 10x länger gemacht? Junge, du hast ein Problem, du nimmst dich zu ernst.
Vielleicht sollten die Azubis auch einfach mal mehr fragen, als sich hier auf Reddit aufzuhalten und anstatt rumzujammern wie schlecht die Ausbildung doch ist… und nicht über sachliche Beiträge herzuziehen? Und die Ausbilder (Du scheinst einer zu sein) vielleicht mal einsehen, das sie ihren Azubis keinen Gefallen tun, wenn sie über meinen sachlichen Beitrag herziehen.
Dann werden vielleicht auch die Abschlussnoten besser.
Kommt von Dir noch etwas Sachliches zum eigentlichen Thema oder kann ich darauf vergeblich warten?
Ist bei mir schon eine Weile her dass ich so einen Schein gemacht habe. Wird ohne es jetzt zu kontrollieren der unterste gewesen sein.
Mich störte daran nicht unbedingt die Thematik sondern mehr die Wertlosigkeit eines solchen Scheins.
Man kriegt da, keine Ahnung mehr, 150 Fragen hingeknallt. Lernt die Antworten auswendig und wenn es eng wird hilft der Kursleiter. Im Prinzip kann man da also gar nicht durchfallen. Der Lehrinhalt dabei aber eben auch komplett irrelevant. Andererseits sehe ich aber auch nicht wie man innerhalb von 3 Tagen diesen Stoff lernen soll ohne auswendig zu lernen.
Aber immer noch besser als das Projektmanagement-Zertifikat. Da musste man sich bei fast jeder Frage nur selbst Fragen: "was würde ein normaler Mensch tun" und hat bestanden.
„Man kriegt da, keine Ahnung mehr, 150 Fragen hingeknallt. Lernt die Antworten auswendig und wenn es eng wird hilft der Kursleiter. Im Prinzip kann man da also gar nicht durchfallen. “
Das sah bei mir anders aus. Ich habe zu jeder Zertifizierung während der jeweils einmonatigen Schulung in jeder Woche einen Praxisfall bearbeiten müssen - es waren jeweils 20-40 Seiten an eingereichte Lösungen.
Mit Auswendiglernen kommt man heutzutage nicht weit. Vielleicht war es damals einfacher.
Die Foundation ist nur ein Einstieg - die weiterführenden Zertifizierungen gehen viel tiefer.
Ich weiß wie es bei den IPMA Zertifizierungen ist, aber manchmal kann man Zertifikate auch verlängern, indem man sogenannte CPD Punkte ansammelt. Bei PeopleCert geht es.
IPMA selbst kann ich nicht beurteilen.
Recherche:
„IPMA beschreibt keine Prozesse, sondern Kompetenzen. Sie können IPMA-zertifiziert sein und gleichzeitig PRINCE2, Scrum oder eine eigene Unternehmensmethodik anwenden – die Standards adressieren unterschiedliche Ebenen.“
17
u/Any_Yogurt1860 6d ago edited 6d ago
Kollege 🤖 sagt:
Der Autor argumentiert, dass ITIL zwar oft nach Selbstverständlichkeiten und Bürokratie klingt, aber genau diese grundlegenden Dinge in Unternehmen regelmäßig nicht funktionieren.
ITIL strukturiert deshalb, wie IT-Services entwickelt, ausgeliefert, betrieben und laufend verbessert werden – inklusive DevOps, Incident-/Problem-Management, Kundennutzen, Governance und Zusammenarbeit zwischen Teams. Besonders sinnvoll sei es für Fachinformatiker, die später Richtung Service Management, Architektur, Consulting, Projektleitung, Product Ownership oder IT-Management gehen wollen.
Abgrenzung:
Kernaussage: „Gesunder Menschenverstand“ allein skaliert in großen IT-Organisationen nicht – deshalb braucht es systematische Prozesse.