Frage an die ITL-Experten: Change- / Problem- / Release Management

[Blain]

Mahlzeit zusammen,

also dass ganze ITIL Thema habe ich eigentlich schon verstanden, nur an einer Stelle habe ich ein Problem mit den Begriffen, und zwar beim Change Management.

• Beim Change Management verstehe ich ja immer die Koordination, Abstimmung, Durchsprache von geplanten Änderungen an IT-Systeme mit Sicherstellung der Verfügbarkeit dieser Systeme d.h. der IT-Betrieb will irgendeine (durch die Entwicklung bereits fertig entwickelt und getestete) Änderung einspielen. Diese Änderungsanträge, die im CAB durchgesprochen werden, sind die RfCs (Request for Change) oder auch kurz Changes.
• Und dann gibts ja noch das "XYZ"-Management, was am Ende des Problem Managements ist. D.h. es gab einen Incident. Die Störung ist nun behoben und man generiert daraus ein Problem-Ticket, um die Ursache zu finden. Dann schafft es irgendwann der Testingenieur den Fehler zu reproduzieren, und es gibt ein "XYZ"-Ticket an die Entwicklung, den Fehler im Code zu beheben. Die Entwicklung behebt dieses "XYZ"-Ticket und lässt die Änderungen in eines der künftigen Releases einfließen. Dieses Release wird dann im Rahmen eines RfCs zum Einspielen beantragt und im Rahmen eines Changes eingespielt. Es geht also um das Ticket an den Entwickler. Im Prinzip ist es Anforderungsmanagement. Anforderungs/Requirement-Management gibts ja lt. ITIL nicht.
• Wie nennt man eine kleine Neuanforderung des Fachbereiches, die man im Rahmen der Wartung realisiert? Das ist im Prinzip ja das gleiche wie nach dem Problem-Management (eine kleine Anpassung), nur kommt es eben aus einer anderen Ecke. Anforderungs/Requirement-Management gibts ja lt. ITIL nicht.

So. Und XYZ wird halt oft auch als Change bezeichnet, aber das ist eigentlich was anderes, weil hier kümmert sich ja noch die Entwicklung darum. Ich hoffe ich konnte Euch mein Verständnis-Problem einigermassen erklären.

Der eine Change ist das Einspielen einer fertigen Software auf dem Produktivsystem, der andere Change ist die Anpassung der Software durch die Entwicklung. Lt. ITIL ist CM das erste.


Danke und Grüße
Blain

ps: Um Links / Literaturverweise die genau auf dieses Thema hinweisen, wäre ich dankbar.

ps2: Oder ist es einfach "Anforderungs/Requirement-Management" und es wird halt in der ITIL nicht behandelt / erwähnt ?

 

[Saugkraft]

Ich hoffe, ich verstehe die Frage richtig.

Du fragst dich, wie das "kleine" Change Management, das sich aus Incidents ergibt, zum "großen" passt, dessen Aufgabe die Implementierung neuer Releases ist?

Am besten, du bleibst bei der Einteilung in die einzelnen Bücher. Stell dir einfach vor, dass es sich hier um "Abteilungen" handelt, die zusammenarbeiten. Und stell dir dabei einen Kreislauf vor (gutes Stichwort auch: Deming Kreis).

Incidents fallen in den Bereich SO (Service Operation). Völlig egal, was daraus wird. Möglich ist, dass aus dem Incident ein RfC wird, muss aber nicht. Das richtet sich letztlich nach dem SLA und der festgelegten Baseline, d.h. nach der Strategie, die die Vorgehensweise regelt. Dazu später mehr. Das Incident Managment ist aber erstmal nur für die akute Handlung beim Auftreten einer Störung verantwortlich. Dem Incident Management ist das Problem Management nachgeordnet. Gehört ebenfalls zum SO. Das Problem Management geht einen Schritt weiter als das Incident Management und kümmert sich um die Analyse statt nur um die Störungsbeseitigung. Das PM kann einen Prozess zur Verbesserung anstoßen (RfC) oder einen Workaround oder eine "Arbeitsanweisung" für das Incident Management festlegen. Hier bewegen wir uns aber immer noch auf der Ebene "Was ist bei xy akut zu tun?".

Wird beim SO festgestellt, dass etwas verbesserungswürdig ist (RfC), kommt das SD (Service Design) ins Spiel. Hier wird festgelegt, welche Strategie man anwendet. Gibt es evtl. ein neues Release (groß, klein), sorgt man für einen schnellen Patch oder stellt möglicherweise einfach nur ein paar Leute ein. Aufgabe des SD ist jedenfalls die Überwachung und Planung der SLAs, die vom SO erfüllt werden sollen.

Wenn im SD festgestellt wird, dass Handlungsbedarf besteht, werden die entsprechenden Prozesse angestoßen. Programmierung, neue SLAs, Handlungsanweisungen für das SO, etc.

Da kommt dann ST (Service Transition) ins Spiel. In dem Bereich kümmert man sich um die Implementierung der Neuheiten. Ein Teil davon ist z.B. das Configuration Management (dem kommt der eher technische Part zu). Ein anderer das Change Management. Das CM hat hier aber nur die Aufgabe, die vom SD geplanten Änderungen entsprechend "an den Mann" zu bringen. Muss evtl. geschult werden, braucht es neue Dokumentationen, etc.

Der eigentliche Change, bzw. die Anforderung läuft aber über das SD, das entsprechend plant und das ST beauftragt.

Der Prozess ist laufend, d.h. es ist natürlich nicht immer ein Major Release erforderlich. Manchmal macht das SO vielleicht das SD nur auf einen Schreibfehler in einer Doku aufmerksam, das dann direkt das ST beauftragt.

Der Kreis ist im Grunde aber immer der Gleiche. Manchmal auf dem "kleinen Dienstweg", manchmal auf dem Großen. Und im richtigen Leben macht das SD vielleicht auch gleichzeitig ST. Von der Prozessstruktur ist das Idealbild aber der Kreislauf SO -> SD -> ST -> SO.. usw.

Überwacht (als losgelösten Prozess) wird das vom CSI (Continual Service Improvement), das übergeordnet das Funktionieren des Kreislaufs überwacht und ggf. die Prozessabläufe/-weitergabe optimiert.

Wird es damit etwas klarer?

 

[Blain]

Hallo,

Danke für die ausführliche Erklärung.

Mit dem großen CM ist gemeint: wann bekommt wer welches Zeitfenster um seine Änderungen auf dem Produktivsystem einzuspielen, ohne dass es einen Business Impact gibt. Man sitzt im CAB mit den Fachbereichen zusammen und macht aus, wann wer was wo am Produktivsystem machen darf. Das sind die Changes, die NACH der Entwicklung gestellt werden.

Die RFCs die aus dem Problem Management kommen, werden ja VOR der Entwicklung erstellt.



Dann ist es also tatsächlich so, dass es 2x einen RfC gibt, einmal im Kontext "Service Design/Service Transition" (Verbesserung/Anpassung von Software) und einmal im Kontext "Service Operation" (Einspielen von fertiger Software auf Produktivsystem)

Ist irgendwie etwas unglücklich, dass man hier immer noch den Kontext zum RFC nennen muss, damit er eindeutig ist.

 

[Saugkraft]

Ist irgendwie etwas unglücklich, dass man hier immer noch den Kontext zum RFC nennen muss, damit er eindeutig ist.

Joa. Jein. Nein. Ja.

Ein Change kann ja theoretisch aus jeder beliebigen Ecke kommen (im Idealfall fühlt sich dazu jeder "Prozessdenker") bemüßigt. Der Servicedesk kann xy vorschlagen. Möglicherweise weil ihn ein Kunde darauf aufmerksam gemacht hat. Dann kommt der RfC aus dem SO. SD oder ST können aber auch einen Change anstoßen. Wenn das SS feststellt, dass die Website modernisiert werden sollte, fällt das in den strategischen Bereich. Genauso wie ein Change aus dem ST, die vielleicht feststellen, dass das neue Release mit dem letzten Windows Update nicht kompatibel ist.

Entscheidend beim Change ist eigentlich die Klassifizierung, nicht so sehr die Herkunft. Bei höchster Priorität und der Kategorie Notfall muss das CAB jetzt nicht unbedingt einberufen werden.

Das ist aber im besten Fall im SLA geregelt und fällt in den Bereich Kapazitätsplanung/Notfallmanagement. Beides SD. Das heißt wiederum: Für die Frage wer darf wann was und welcher Change wird wie behandelt, sollte es einen Plan geben.

Vor dem Release im Sinne VOR der Entwicklung sollte also die gleiche strategische Behandlung genießen wie im akuten Fall, d.h. bei der Implementierung. Klartext (plump gesagt): Wenn das nicht klar ist, hat das SD die Prozesse nicht vollständig abgebildet.

Das SD ist ja letztlich dafür verantwortlich, sollte Konflikte mit geeigneter Einsatzplanung und passenden SLAs zu vermeiden. Egal, woher der RfC konkret kommt.

Die Kategorisierung und Priorisierung ist in der Praxis eine sch.. Aufgabe. Daran scheitert es oft. Oder schlicht daran, dass der Fall "Chef fährt mit dem Porsche den Server kaputt" noch nie aufgetreten ist.

Prozessual sollte das aber geregelt sein.

 

[Blain]

Ja aber nochmal: dann kann doch ein change entweder
1) ein Antrag zur Änderung einer Software durch die Entwicklung
Oder
2) ein Antrag zum Einspielen einer FERTIGEN Software durch den Betrieb sein

Oder? Das sind 2 komplett unterschiedliche Sachen. Das ist die alles entscheidende Frage...

Ich wenn von einem Change rede oder auch die Bücher, dann geht's immer im 2)

 

[Blain]

Oder anders rum: alles was unter 2) läuft, trage ich in das Changemanagement Modul der ITSM ein. Das CAB entscheidet, ob es produktiv geschaltet wird.

In welches System trage ich die 1) ein?

 

[wegus]

Was bin ich froh, dass ich in kleinen Strukturen unterwegs bin und mir solche Wasserkopfprobleme ersparen kann. Ab einer gewissen Größe geht es ganz sicher nicht mehr anders, aber wenn ich das alles lese finde ich es wenig erstrebenswert die zu erreichen

 

[djofly]

Sei froh. Wenn man Langeweile hat und sein Unternehmen stilllegen will, dann führt man dieses Prozessmanagement nach ITIL ein.

 

[asterixxER]

Sei froh. Wenn man Langeweile hat und sein Unternehmen stilllegen will, dann führt man dieses Prozessmanagement nach ITIL ein.

Generell ist Itil nicht schlecht, nur das wie, daran scheiden sich die Geister. Leider gibts immer wieder Auslegungen die aus einer Arbeiterleichterung (weil klar ist wer fuer was zustaenig ist etc.) eine Kathastrophe machen (Was? Sie wollen Datei von x nach y kopieren? dazu brauchen sie aber einen Change....).

 

[Saugkraft]

In welches System trage ich die 1) ein?

Typische IT-Antwort. Das kommt drauf an.

ITSM hat mir ITIL ja erstmal nichts zu tun. Ein ITSM ist eigentlich nur ein Tool, das bestimmte ITIL Prozesse abbilden kann. Nochmal: ITIL ist ein Prozessmanagement-Handbuch. Keine Abbildung der realen Prozesse.

Wenn euer ITSM nur einen Fall abbildet, bildet es die ITIL Prozesse nicht vollständig ab. Im Zweifelsfall ist für 1) gar nichts vorhanden.

Das ist wie die Unterscheidung Datenbank und Datenbankmanagementsystem. Die Datenbank kann Oracle oder mySQL sein, das DBMS theoretisch Access, eine Weboberfläche oder sonst ein Tool.

Sei froh. Wenn man Langeweile hat und sein Unternehmen stilllegen will, dann führt man dieses Prozessmanagement nach ITIL ein.

Wenn das Unternehmen stillgelegt wird, hatte jemand keine Ahnung von ITIL.

Genau das soll ITIL ja verhindern. Dummerweise nehmen manche Consultants ITIL zu wörtlich. Das Ding ist aber erstmal nur ein Leitfaden, der bestimmte Prozesssichten und Funktionssichten definiert und die Strukturierung erklärt.

Alternativ kannst du deine IT auch mit ARIS strukturieren. Nimmt sich wenig.

Zum Vergleich: Ritz Carlton (Hotelkette, mehrfacher Gewinner vom Malcolm Baldrige Award für Qualitätsmanagement) benchmarkt sich gerne mal mit Industrieunternehmen. Deshalb verkaufen die noch lange keine Kopierer oder Taschenrechner. RC hat übrigens wiederum das Apple Store Konzept inspiriert. Übernachtungen gibt es da trotzdem noch nicht.

Insofern: ITIL ist ein hervorragendes Konzept. Aber eben auch nur das. Wenn es shaize läuft, ist die Implementierung Mist.

 

[stuart]

Meine Fresse, was bin ich froh nicht mit irgendeiner Branche zu tun haben zu müssen, in der jedes zweite Wort so ein Denglisch-"Fachbegriff" ist bei dem bald keine Sau mehr durchblickt was eigentlich irgendwer macht...

 

[Saugkraft]

Meine Fresse, was bin ich froh nicht mit irgendeiner Branche zu tun haben zu müssen, in der jedes zweite Wort so ein Denglisch-"Fachbegriff" ist bei dem bald keine Sau mehr durchblickt was eigentlich irgendwer macht...

Och, das geht. Ist halt (eigentlich) auch ein Lernberuf. Die einen lernen, was eine Presspassung ist, die anderen, wie man Teig führt, die nächsten, was Incident Management bedeutet.

Finde ich jetzt nicht so dramatisch. Shaize wird es, wenn der Kundenbetreuuer zum Key Accounter wird und keine Sau mehr durchblickt, wer eigentlich welche Fachkompetenzen hat, weil alle den Penisabdruck von Long John Silver auf der Visitenkarte haben.

Oder anders ausgedrückt: Qualität ist Managementaufgabe. Wenn der Key Accounter (Key Account: Nachhaltige Betreuung wichtiger Kunden) keine Entscheidungskompetenz oder keine Freigaben hat/bekommt, dann ist das Ergebnis nur eine Karikatur.

In welcher Branche bist du?

 

[stuart]

In welcher Branche bist du?

Irgendwas mit Medien

Bis jetzt bin ich zum Glück an solchen Bezeichnungen und Ausflüssen von Key Account Asshole & Asswipe Conformity Eternal & External Supply Chain Management und Artverwandten verschont geblieben und ich hoffe mal inständig, dass das auch möglichst lange so bleibt.

 

[djofly]

Qualität ist Managementaufgabe.

Ein entscheidender Satz!

 

[Saugkraft]

Irgendwas mit Medien

Dann stell dir einen Art Director vor, der den Unterschied zwischen Digital- und Offsetdruck nicht genau kennt. Es gibt dann aber auch die "richtigen", die das mal gelernt und viel Erfahrung haben.

Ich weiß nicht, wie es bei euch ist, aber wenn jeder Heini zum AD befördert wird, dann ist das Problem nicht das Denglisch, sondern die Tatsache, dass da ein Heiopei am werkeln ist.

Ein entscheidender Satz!

Leider gerade in der strategischen IT und/oder Unternehmen mit einer strategischen IT völlig unterrepräsentiert.

Wenn du Prozesse nicht verstehst, geht das früher oder später daneben. Ein guter ITler muss bei jedem Stein sagen können, was drunter liegt. Egal ob er selbst drunter gekrochen ist oder nicht. Aber er muss es wissen. Und er muss jederzeit wissen, was passiert, wenn du Knopf xy drückst. Angefangen beim Kundenerlebnis bis hin zur Arbeit der internen Kunden.

Erwarte ich eigentlich auch von der Geschäftsführung. Da regiert in vielen Unternehmen aber nicht Kompetenz, sondern Kennzahlen. Die sind aber ein Hilfsmittel. Kein Erklärungsansatz.

Ich bin ein großer Fan von dieser Art von Management: http://en.wikipedia.org/wiki/Nordstrom

 

[Blain]

Hallo zusammen,

zum Thema ITIL an sich: Ab einer bestimmten Größe muss man halt nach gewissen regeln arbeiten, weil sich die Aufgaben über mehrere Köpfe verteilen. In einem Großkonzern mit mehr als 100.000 Mitarbeitern und 5.000 Leuten in der IT gehts leider nicht anders. Aber man kann alles auch übertreiben. Wichtig ist, dass man es halt richtig einsetzt. Aber ich will hier keine Diskussion über ITIL an sich lostreten, sondern eigentlich nur dieses eine Thema "Change-Management"

1) ein Antrag zur Änderung einer Software durch die Entwicklung (Bewertet der Entwickler)
Oder
2) ein Antrag zum Einspielen einer FERTIGEN Software durch den Betrieb sein (Bewertet das CAB mit Fachbereichen und dem ChangeManager)

So richtig weitergebracht hat mich die Diskussion leider noch nicht...

In unserer ITSM Suite "BMC Remedy ITSM" kann ich nur Changes einstellen, die unter 2) also zum Einspielen einer fertigen Software in das Produktivsystem. Ein Einstellen eines Changes an die Entwicklungsabteilung zur Änderung der Software kann man nicht erstellen, sondern dafür gibts leider ein eigenes Tool.


Grüße
Blain