Change Mangement Literatur

Vielleicht bin ich hier bei einem Programmierforum auch einfach an der falschen Stelle. Habe es einfach mal versucht, aber wird wohl nichts draus wenn nur "Bahnhof" daraus verstanden wird...

Ist in dem Fall etwa das gleiche, wie wenn ein Programmierer ein C++ Frage in ein Daniel-Küblböck-Forum stellt

IT ist in dem Fall doch nicht gleich IT

Der einzige der hier was darüber wissen könnte ist Prof84.

Prof84

FH_Student schrieb:

Ich schreibe gerade an meiner Diplomarbeit mit dem Thema "Konzept für Change Management im Bereich Windows-Standard-Applikationen und Windows-Betriebsystem".

*kopfschüttel* Wofür heutzutage bereits Diplome vergeben werden ...
<zyn>Und wieder ein Kandidat für die Dauerarbeitslosigkeit ... </zyn>

FH_Student schrieb:

Kennt jemand von euch zufällig einige gute Bücher über Change Management vorallem mit Schwerpunkt Release- und Patchmanagement?

Nö! - Könnte aber auch darin liegen, dass Du "Change Management" sagst, aber "Configuration Management" meinst ...

FH_Student schrieb:

Im Prinzip geht es hier um ITIL und auch hier gibt es einen Haufen Bücher. Nur würde ich eben gerne mit den obenerwähnten Schwerpunkten was finden...

Muss daran liegen, dass Du U-Boote mit Bananen keutzt ...
</laesster>

<literaturhinweise mode="konstruktiv">
Also als Erstes würde ich Dir mal auf das Auge drücken herauszufinden, wo die Unterschiede zwischen Requirement, Change, Risk and Configuration Management ligen. Diese Themen gehen nämlich hand-to-hand. Dazu empfehle ich Dir folgende Bücher (Meisterwerke ) zur Theorie:

Kontinuierliches Anforderungsmanagement | ISBN: 3827317878

Komponentenbasierte Softwareentwicklung mit MDA, UML 2 und XML | ISBN: 3446229159
( laß Dich Durch den Titel nicht täuschen. Der Roadtripp durch modernste Erstellungsmethoden umfasst auch RM, ChM, RiM und CoM.)
</literaturhinweise>

<links mode="konstruktiv">
Am besten kann man die Prozesse des Re-Ch-Ri-CoM Managements verstehen,
wenn man sich mit den zugehörigen Tools beschäftigt.

RM:
http://www-306.ibm.com/software/awdtools/reqpro/
http://www.telelogic.com/products/doorsers/index.cfm

ChM:
http://www-306.ibm.com/software/awdtools/clearquest/
http://www.telelogic.com/products/synergy/changesynergy/index.cfm

CoM:
http://www-306.ibm.com/software/awdtools/clearcase/
http://www.telelogic.com/products/synergy/cmsynergy/index.cfm
http://www.cmcrossroads.com/ubbthreads/ubbthreads.php?Cat=&C=5

http://www.itilsurvival.com/ITILChangeManagement.html
</links>

Und jetzt kann mann sich noch die intelligente Frage stellen, was die Softwaretechnik damit zu tunen hat....

cu
P84

Prof84

Schau mal, was man da noch in der Suchmaschine findet :

http://www.google.com/custom?domains=www.cmcrossroads.com&q=change+management&sitesearch=www.cmcrossroads.com&client=pub-2730222521232680&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23008000%3BGL%3A1%3BDIV%3A%23999999%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AFFFFFF%3BALC%3A000000%3BLC%3A000000%3BT%3A000000%3BGFNT%3A0000FF%3BGIMP%3A0000FF%3BLH%3A36%3BLW%3A250%3BL%3Ahttp%3A%2F%2Fcmcrossroads.com%2Fimages%2Fcmclogo250.jpg%3BS%3Ahttp%3A%2F%2Fcmcrossroads.com%2F%3BFORID%3A1%3B&hl=en

cu
P84

Zuerst mal danke für deine Antwort. Hätte nicht gedacht dass ich hier einen Crack zu dem Thema finde... Ziel erreicht

Kurz zu deiner "Kritk". Habe nicht ganz so null Ahnung wie du das darstellst und ist schon so gemeint wie beschrieben. Der Titel ist aber in dem Fall noch etwas unglücklich geraten.

Im Prinzip geht es mir darum, was alles passiert wenn der Fall eintritt, dass man eine neue Applikation oder ein Patch einführen muss (warum auch immmer, Virus, neue Funktionen, stategisch, etc.)... den ganzen Prozess beschreiben inklusive auf welche Schwierigkeiten man im Alltag trifft.

Und das ganze will ich im ITIL abbilden (umfasst Service Desk, Inciden Mgmt, Problem, Mgmt, Change Mgmt, Release Mgmt, SLM, eben das volle Programm). Dabei will ich mich aber eben nur auf den oben genannten Bereich beschränken und nicht ein ganzes Change Management einführen...

Das ganze will ich dann mit dem Faktor Mensch (-> Kommunikation, Widerstände) verbinden, welches im ITIL nicht eingegangen wird.

Es ist mehr eine praxisbezogene Diplomarbeit (mit weniger wissenschaftlicher Erkenntnis als Ziel), da ich auf dem Bereich Software-Packaging arbeite (und nicht nur studiere... das zum Thema arbeitslos)

Deine Links beziehen sich eher für Entwickler/Programmierer. Ich will die Arbeit aber eben eher als Konzept ansehen und anhand von dem dann das Ganze Schritt für Schritt bei meinem Arbeitgeber implementieren (was aber nicht Teil der DA ist).

In welchem Zusammenhang kennst du dich bei dieser Materie so gut aus?

Prof84

FH_Student schrieb:

Zuerst mal danke für deine Antwort. Hätte nicht gedacht dass ich hier einen Crack zu dem Thema finde... Ziel erreicht

Ja?! - Wo ist er denn?

FH_Student schrieb:

Kurz zu deiner "Kritk". Habe nicht ganz so null Ahnung wie du das darstellst und ist schon so gemeint wie beschrieben. Der Titel ist aber in dem Fall noch etwas unglücklich geraten.

Nicht persönlich nehmen, dass ist meine charmante Art Deine Aufmerksamkeit zu gewinnen. Die Nummer ziehe ich sogar mit Kunden ab ...

FH_Student schrieb:

Im Prinzip geht es mir darum, was alles passiert wenn der Fall eintritt, dass man eine neue Applikation oder ein Patch einführen muss (warum auch immmer, Virus, neue Funktionen, stategisch, etc.)... den ganzen Prozess beschreiben inklusive auf welche Schwierigkeiten man im Alltag trifft.

Habe ich auch so verstanden.

FH_Student schrieb:

Und das ganze will ich im ITIL abbilden (umfasst Service Desk, Inciden Mgmt, Problem, Mgmt, Change Mgmt, Release Mgmt, SLM, eben das volle Programm). Dabei will ich mich aber eben nur auf den oben genannten Bereich beschränken und nicht ein ganzes Change Management einführen...

http://www.itilsurvival.com/default.asp
Ist so eine Argumentation wie - "Ich will nur einen Fernseher bauen. Warum soll ich mit Fertigstechnik beschäftigen. Ich brauche nur "normale Teile".
IHMO kannst Du die Libary in die Tonne kloppen. Denn es gibt kein allgemeingültiges Kochrezept für Changemanagement etc.

FH_Student schrieb:

Das ganze will ich dann mit dem Faktor Mensch (-> Kommunikation, Widerstände) verbinden, welches im ITIL nicht eingegangen wird.

Ohne Beruferfahrung?!? - Das ist so als wenn ein Blinder von der Farbe spricht ...
Willst Du eine Tabelle erstellen. Von Persönlichkeitsprofil "aufgeschlossen liebevoll handzarm" bis "dummes sturres A.-loch" hast Du in der Praxis alles dabei. Und genau dieser Faktor Mensch ist es, der Dir in der Praxis sämtliche ausgearbeiteten Konzepte über den Haufen wirft. (Softskills)

FH_Student schrieb:

Es ist mehr eine praxisbezogene Diplomarbeit (mit weniger wissenschaftlicher Erkenntnis als Ziel), da ich auf dem Bereich Software-Packaging arbeite (und nicht nur studiere... das zum Thema arbeitslos)

Na bitte! - Also doch Berufserfahrung!

FH_Student schrieb:

Deine Links beziehen sich eher für Entwickler/Programmierer. Ich will die Arbeit aber eben eher als Konzept ansehen und anhand von dem dann das Ganze Schritt für Schritt bei meinem Arbeitgeber implementieren (was aber nicht Teil der DA ist).

Wie jetzt?! - Doch kaum Berufserfahrung!
1. Frage: Welche PM-Methode erlaubt ein Schritt-für-Schritt-Vorgehen und wie sieht das aus? - RUB, OEP, XP, Cristal, V-Modell, Wasserfall-M., Spriral-M., AE, CMM, CMMI ...
2. Frage: Worin liegt der Unterschied zwischen ChM und RM.
3. Frage: Gibt es eine Verbindung zwischen RM und dem Entwickeln?

FH_Student schrieb:

In welchem Zusammenhang kennst du dich bei dieser Materie so gut aus?

Ich war in zwei Projekten Requirement Engineer und einen Projekt zeitweilig Produktmanager. Weiterhin consulte ich überwiegend nur Software- und IT-Unternehmen. Z.Z. bin ich bei einen bekannten Elektonikkonzern als Senior RM und Coach im Gespräch. (Nicht weil dazu besonders qualifiziert bin, sondern nur das kleinste Übel .)

Aber anonym protzen kann jeder ...

ITIL in die Tonne werfen? Klar gibt es kein allgemeingültiges Rezept. Es gibt aber "Best Practise", welcher sich von der Theorie unterscheidet. Auch gibt es verschiedenste andere Methoden (z.b. ITPM, MOF, COBIT, etc.) und ich habe mich davon für ITIL entschieden. Auch darum, da es mir persönlich am erfolgsversprechenden klingt für die Zukunft (nach Studien, Umfragen, etc.)

Auch beschränke ich mich auf diesen Teil der Applikationen und Patches, da es hier am meisten Potential zum optimieren gibt (jetzt nicht nur bei meinem Arbeitgeber). Das mit dem TV-Beispiel kann man wohl eher so sehen, dass man den ganzen Prozess vom Eingang der Bestellung bis zur Auslieferung vorgibt (WAS sollte man beachten), ohne in die produktive Fertigung technisch einzugehen (das WIE ist uninteressant in dieser Arbeit).

Und genau wegen deiner Feststellung, dass der Faktor Mensch alle Konzepte über den Haufen wirft, nehme ich ja diesen wichtigen Teil mit in die Arbeit ein.

Wie jetzt?! - Doch kaum Berufserfahrung!
1. Frage: Welche PM-Methode erlaubt ein Schritt-für-Schritt-Vorgehen und wie sieht das aus? - RUB, OEP, XP, Cristal, V-Modell, Wasserfall-M., Spriral-M., AE, CMM, CMMI ...
2. Frage: Worin liegt der Unterschied zwischen ChM und RM.
3. Frage: Gibt es eine Verbindung zwischen RM und dem Entwickeln?

Irgendwie habe ich das Gefühl, wir schreiben einander vorbei.

Prof84

FH_Student schrieb:

Irgendwie habe ich das Gefühl, wir schreiben einander vorbei.

Joh, ist mir klar.
Vielleicht liegt aber gerade in der Kontroverse ein guter Ansatz für einen roten Faden bei Deiner Diplomarbeit.

FH_Student schrieb:

ITIL in die Tonne werfen? Klar gibt es kein allgemeingültiges Rezept. Es gibt aber "Best Practise", welcher sich von der Theorie unterscheidet. Auch gibt es verschiedenste andere Methoden (z.b. ITPM, MOF, COBIT, etc.) und ich habe mich davon für ITIL entschieden. Auch darum, da es mir persönlich am erfolgsversprechenden klingt für die Zukunft (nach Studien, Umfragen, etc.)

Nur weil einige sagen - "Das ist ein gutes Kochbuch!" - und Du hast es gelesen, kannst Du noch lange nicht Kochen.

Nur nur weil Du eine Menge Kochrezepte ("best practise") gekauft hast, weiß Du noch lange nichts über die Grundprinzipien des Kochens.

Es ist für mich ein Hohn zu behaupten, wenn Du den Workflow der ITIL durchpeitschst, verstehst Du irgendwas von IT Management.

Ich rede von echten Managementmethoden ("Grundprinzepien des Kochens").
Analog - ich weiß was zu tunen ist, wenn "keine Eier mehr da sind" (Changemanagement). Während Du mit deinen Kochrezept in Panik verfällst ...

Ich weiß, wie man Kochrezepte kombiniert (Konfigurationsmanagement).
Oder wie ich ein Dinner vorbereite (Anforderungsmanagement).
Ob und wieviel ich mehr kochen muss, weil wieder unerwarte Gäste auftauchen (Risikomanagement).
Oder der menschliche Faktor: "Das mag ich nicht! "

Ziel einer Diplomarbeit ist es das Gelernte in Zweifel zu ziehen und mit etwas Eigenen zu kombinieren.

Also schnapp Dir ein Feuerzeug und fang an Deinen eigenen Kopf zu gebrauchen.

Schön gesagt! Ich weiss was du meinst. Aber ich denke meine Ansprüche sind bei weitem nicht so hoch wie deine an meine

Ich will das Rad nicht neu erfinden, schaue mich darum auf den Markt um, was es für bestehende Methoden es gibt, wähle es nach bestimmten Kriterien aus (in dem Fall ITIL), zeige den ganzen "Leitfaden" auf und vergleiche danach, wie mein Arbeitsalltag im Moment und danach mit ITIL aussehen könnte.

Mische dazu noch meine gelernten Theorien aus PM und Benutzerservice über den Faktor Mensch inklusive 5 jähriger Erfahrung angefangen bei Helpdesk bis zu einer kompletten XP Migration und rauskommt dabei meine Erkenntnis, die nicht irgendwo schon vorgeleiert steht, sondern selbst"erkannt" ist

So wie ich dich jetzt verstehe, würdest an meiner Stelle eventuell versuchen, ein komplette neue Methode aus allen Erkenntnissen, Erfahrungen und Theorien zu erstellen die du bsi jetzt hast.... Aber das ist mir dann doch zu viel Aufwand, bzw. wäre ich noch gar nicht in der Lage dazu so was komplexes zu erstellen (mangels Erfahrung, Intelligenz, etc.)

Trotzdem sehr interessante Diskussion mit dir Wieviele Jahre Berufserfahrung hast du eigentlich? Kann mir nicht vorstellen, dass du all dein Wissen bei einer FH oder UNI aufgefangen hast... da muss schon mehr dahinter sein.

Prof84

Tu mir einen Gefallen und lasse den Begriff "Methode" bei ITIL weg - Leitfaden trifft es ganz gut.

Ich habe nicht gesagt, dass Du eine neue Softwareerstellungsmethode entwerfen solltest. Aber vielleicht wäre es ein guter Ansatz, die betreffenden Punkte der ITIL unter Betrachtungen gänger Projektvorgehensmethoden z.B. XP oder RUP zu beleuchten.

Aber Schwerpunktthema ist immer noch das Change-Management. Ich zitiere mal Schienman:

3.5.2 Änderungsmangement

In vielen Publikationen zur Softwaretechnik wird Änderungsmanagement und Anforderungsmanagement fast synonym verwendet. Das Management der Änderung von Anforderungen ist eine zentrale Aufgabe der Softwareentwicklung, da einerseits die Planung von Projekten auf der Grundlage der Anforderungen erfolgt, diese sich anderseits im Laufe eines Projektes aber permanent ändern. Alle Studien zu Änderungen zeigen, dass der systematische Umgang mit Änderungsanforderungen ein kritischer Erfolgsfaktor im Projekt ist.

Der in diesen Buch beschriebener Ansatz zielt auf ein unternehmensweites Änderungsmanagement (sog. Enterprice Change Management, ECM) für einen kontinuierlichen, durchgängigen Softwareerstellungsprozess, wie ihn etwa auch das Institute of Configuration Management ihrem Ansatz CMII (Configuration Managemnt II) für einen allgemeingültiges Konfigurationsmanagement zugrunde legt.

Zwei Fragen:

Haben wir es bei Patch- und Releaseerstellung mit einer unternehmensweiten Änderung zu tunen?
Haben wir es dabei mit Konfigurationsmangement zu tunen?

Finden diese Aspekte Berücksichtigung in der ITIL?

FH_Student schrieb:

Trotzdem sehr interessante Diskussion mit dir Wieviele Jahre Berufserfahrung hast du eigentlich? Kann mir nicht vorstellen, dass du all dein Wissen bei einer FH oder UNI aufgefangen hast... da muss schon mehr dahinter sein.

9 Jahre Projekterfahrung. Ich besitze keine Ausbildung in der Informatik, Betriebswirtschaft oder IT-Management. Daher bin ich Wege gegangen, die effizient sind ...

In Ordnung, Methode ist das falsche Wort. Leitfaden ist klar. Denke dass aber auch Framework oder Modell passt oder?

Zwei Fragen:

Haben wir es bei Patch- und Releaseerstellung mit einer unternehmensweiten Änderung zu tunen?

Haben wir es dabei mit Konfigurationsmangement zu tunen?

Finden diese Aspekte Berücksichtigung in der ITIL?

Das hängt davon ab, ob der Incident eventuell Teil eines Projektes ist, welches eine unternehmsweite Änderung als Ziel hat

Ich denke wir dürfen das nicht vermischen. Ein Projekt sollte nicht über ITIL oder ähnliche Strukturen abgewickelt werden, sondern braucht eben ein eigenständiges Projektmanagement und entsprechende Methoden. ITIL betrifft es hierbei nur zum Teil, wenn ein Änderungswunsch eintrifft, der die IT-Infrastruktur betrifft. Zum Beispiel wenn ein neues Software-Produkt entwickelt wurde (in einem Projekt) und in der bestehenden IT-Umgebung implementiert werden muss. Dann betrifft dass im ITIL jetzt in meinen Bereich, diese Applikation auf bestehende PC's zu installieren (mit Repackaging, Softwareverteilung etc.). Und dabei entscheidend für mich ist, dass alles einen geregelten Ablauf hat, vom Incident-Eingang bis zur Änderung selbst. Wie die Software entwickelt wurde etc. kann mir in diesem Punkt egal sein. Das hoffe ich, werden unsere Entwickler schon selber wissen, wie man das am besten macht (mit welcher Entwicklungsmethode auch immer).

Eine Frage stellt sich aber mir und geht bis jetzt noch nicht klar irgendwo heraus. Vielleicht weisst du das. Mein Arbeitsbereich (Softwareverteilung, Repackaging) müsste nach meiner Meinung nach IITL im Release Management angesiedelt sein. Anscheinend nennt man das nach ITIL Software Mgmt. Es gibt aber auch das Application Mgmt was wahrscheinlich eher deinen Vorstellungen betrifft und Methoden für einen ganzen Lifecycle einer Applikation zur Verfügung stellt. Damit wäre ich mich aber nicht tiefer beschäftigen. Wollte nur wissen was du zu dem meinst...