Google hat nun im Google+ die Communities freigeschaltet.
Der Blog wird damit nun hier fortgeführt:
Google+ Community IT Management

Stages towards business orientation for it-organisations

I think there are some more stages than component orientation and service orientation in IT organisations which makes it easier for organisations to make progress on this long road visible:

1.  Purely technical orientad organisations don't manage IT really. They operate technical items as good as they personally can.
2.   Product orientated organisations know the connections between products (e.g. applications) and there specific operation envirements.
3. Component orientated organisations are able to manage less operations envirements than products exist. They manage technical services as a technical serviceprovider.
4.   Customer focused organisations often try to fulfill the customer expactations, but "forget" the technical abilities and costs. Selling is everything...
5. Service orientated organisations are able to close this gap between customer expactions and provider abilities.
6. The most challenging model is in my opinion the business orientation: The IT organization is able to manage services by maximizing the efforts for customers and the business.

Follow the discussion on Linkedin.com

Auswahl des geeigneten Vorgehensmodells im Projektmanagement

Scheitern Projekte am schlechten Vorgehensmodell oder an der fehlenden fehlende Adoption und Verankerung der  Methoden des Modells in den tagtäglichen Arbeitsweisen?


Posting auf XING: Ausgehend von der Grundannahmen, dass 87% der deutschen Unternehmen ein Vorgehensmodell einsetzen und nur 32% aller IT-Projekte erfolgreich abgeschlossen werden, kann man zu der Erkenntnis kommen, dass dies u. a. an dem falschen Vorgehensmodell liegt. Dies führt zu meiner These, dass es einer Entscheidungsunterstützung bedarf, die individuell für jedes Projekt das geeignete Vorgehensmodell wählt.
Mein erster Gedanke: Wenn fast alle Unternehmen ein Vorgehensmodell für Projekte haben und trotzdem nur eine Minderheit Projekterfolge verzeichnen, muss das nicht am "falschen" Vorgehensmodell liegen. 

• Was nützen mir die besten Vorgaben eines Modells, wenn Sie nicht konsequent angewendet werden? 
• Was bringt mir ein Modell, wenn Bausteine des Modells wie Planung, Zieldefinition, Teamauswahl etc. in der Praxis weder durchgeführt noch eingefordert werden? 
• Was bedeutet eigentlich "setzen ein Vorgehensmodell ein" konkret? 
• Ist das Modell dokumentiert, bekannt, akzeptiert und angewandt oder handelt es sich um die berühmte Paperware oder Schrankware - wurde das in der Untersuchung ermittelt? 
• Würden dann nicht mehrere zur Auswahl stehende Modelle eher noch mehr Schrankware bedeuten? 

Nach meiner Beobachtung ist weniger die fehlende Kenntnis oder Geeignetheit von Methoden und Vorgehensmodellen im Projektmanagement Grund für ein scheitern von Projekten als vielmehr die fehlende Adoption und Verankerung dieser Methoden in den tagtäglichen Arbeitsweisen - getreu dem Motto: "Ich weiß schon, dass ich es anders machen sollte, mache es aber trotzdem nicht so...." 

• Ist die Grundannahme einer Korrelation von vorhandenem Vorgehensmodell und Projektmisserfolg richtig? 
• Ist  ein Scheitern von Projekten auf ein ungeeignetes Vorgehensmodell zurückzuführen? 
• Gibt es Aussagen, ob die Ursache für eine fehlende Adoption und Institutionalisierung von Methoden der Vorgehensmodelle im "schlechten Modell" liegt oder an der herausfordernden Aufgabe, Arbeitsweisen und organisations-kulturelle Prägungen zu verändern? 

Zwischen Plan und Chaos in der IT-Organisationsentwicklung

Das ist so eine Sache mit den organisatorischen Veränderungsmaßnahmen in der IT. Erkennen wir immer das wirklich Notwendige? Stoßen wir hier immer das Wichtige an? Und setzen wir die Maßnahmen dann richtig auf?

Ich möchte Ihnen heute Impulse für die Entwicklung Ihrer effektiven IT-Prozess-Strategie liefern:

IT-Organisation muss sich verändern. Vor 40 Jahren lag der wesentliche Effizienzhebel noch im Hardwareeinkauf. Heute machen sich 70-80% der Performance von IT-Bereichen an der Leistungsfähigkeit der eigenen Arbeitsweise, der Steuerbarkeit externer Dienstleistungen und dem optimalen Einsatz von Software fest. Benötigt werden hierfür vor allem andere Rollen, fähige Prozesse und geeignete Strukturen.

Aber welche konkreten organisatorischen Veränderungen benötigen wir nun wann in welchem Umfang? Und werden hiermit tatsächlich Verbesserungen für unsere Anwender und IT-Mitarbeiter sichtbar? Wirken unsere Maßnahmen eher zielgerichtet oder opportunistisch?

Wir brauchen einen belastbaren Umsetzungsplan für IT-Organisationsentwicklung, der unsere Optimierungsmaßnahmen im Zusammenhang behandelt und sowohl die dringlichen Lösungen als auch die nachhaltigen Veränderungen gangbar macht.

Zur richtigen Veränderungsstrategie kann das IT-Führungsteam systematisch und mit erstaunlich wenig Aufwand kommen.

Aus der Praxis leiten sich vielleicht drei besonders kritische Fragen zum richtigen Setup von Veränderungsmaßnahmen ab:

1) Strategie: 
Wie kommen wir aus der Tretmühle der vielen Einzelmaßnahmen heraus, hinter denen oft zu wenig langfristige Strategie erkennbar ist?

2) Problemorientierung: 
Wo setzen wir richtige Prioritäten, um mit knappen Ressourcen genau die Veränderungen zu treiben, die einen wesentlichen Hebel für Verbesserung liefern?

3) Veränderungsfähigkeit: 
Warum erleben wir in der Umsetzung so häufig Ernüchterung auf allen Seiten und ist das vermeidbar?

Wenn wir diese Fragen im Zusammenhang sehen, erkennen wir recht leicht, warum viele gut gemeinte Initiativen letztendlich nicht die Kraft auf die Straße bekommen. Hieraus leiten sich konkrete Anforderungen an ein effektives Vorgehen auf dem schnellen Weg zur gezielten Prozess- und Veränderungsstrategie ab.

Lesen Sie hier einfach weiter, wenn Sie mehr darüber und über unsere Methodik erfahren möchten: http://www.hisolutions.com/HiS_Statements/HiS-Statement_Stra...

Wenn Ihnen dieses Statement Impulse für Ihre erfolgreiche Arbeit liefern konnte, freue ich mich auf Ihr Feedback!

Why is the Business Relationship Management Process in #ITIL 2011 not a function?

“A function is a team or group of people and the tools or other resources they use to carry out one or more processes or activities. (Quelle: ITIL 2011)”

In der Service Strategy von ITIL 2011 wird nun ein neuer Prozess beschrieben – das Business Relationsship Management. Hier werden Aufgaben des Business Relationship Managers wie folgt beschrieben:

“For many organizations, the role of the business relationship manager (BRM) was established to execute certain customer-facing activities in various processes… the BRM often represents other processes when engaged in business relationship management – for example,... service portfolio management, demand management and capacity management. Thus, it may seem unclear as to which process the BRM role is executing….Business Relationship Managers are often required to execute activities from other processes simply because of their customer-facing position (Quelle: ITIL 2011).”

Und auch noch:

“The business relationship management process... is rarely executed as a single end-to-end process (Quelle: ITIL 2011). “

Hätte man den BRM-Prozess nicht dannn auch als BRM-Funktion beschreiben können?

ITIL V3 2011: Stärkung der Service- und Kundenorientierung – aber wohl kein Befreiungsschlag

Heute hatte ich die Gelegenheit an einem Webinar zum Titel „ITIL v4? – What’s Next?“ teilzunehmen.
Die Inhalte möchte ich hier kurz wiedergeben:
Zunächst sprach Vernon Lloyd (International Client Director bei Fox IT und Mitautor der ITIL V3 2011 Edition) über Neuheiten der ITIL V3 2011 – Edition:

Was wir erwarten können: 

• Neue konsistente Struktur in allen Büchern
• Neue Struktur und neue Inhalte in allen Prozesskapiteln
• Schnittstellen zwischen Prozessen wurden erweitert

Welche Neuheiten gibt es in den einzelnen Büchern?

• In der Service Strategy gibt es zwei neue Prozesse „Strategy Management“ und „Business Relationship Management“. Daneben wurden viele der wirren Diagramme und Abbildungen in der Service Strategy ersetzt oder herausgenommen.
• Im Buch Service Design gibt es einen neuen Prozess "Design Coordination" und Ergänzungen im Service Catalogue Management
• In der Service Operation und Transition wurden die Prozessdarstellungen für Change, Incident und Problem Management angepasst und das proaktive Problem Management wurde erweitert.
• Im CSI wurde ein neues Konzept "CSI register" geschaffen, der 7-Step-Improvement-Process stellt sich nun konsistenter dar. Insgesamt wurden die Konzepte rund um den Deming Cycle, den CSI approach (bisher CSI Model) und das Knowledge Management optimiert.

Zu der im Umlauf befindlichen hohen Anzahl von 600 neuen Seiten meinte er, dass er dies aktuell nicht nachvollziehen könne. Die Gesamtzahl der Seiten nicht gestiegen sei, sondern vor allem die Kapitelzusammenstellung geändert wurde.

Stephen Mann von Forrester stellt fest, dass die ITIL-Adoption heute schon viele Organisationen überfordert. In einem Rückblick stellt er dar, dass der tatsächliche Umsetzungsfokus der ITIL V2 auf den reaktiven Support Prozessen mit nur geringer Reife auf den Delivery Prozessen lag. Er stellt fest, dass auch heute noch viele Organisationen diesen Reifesprung, der mit der Serviceorientierung der ITIL V3 einherging nicht geschafft haben und es einen eher geringen Integrationsgrad der V3-Prinzipien gibt. Sein Wunsch für eine ITIL V4 / ITIL 2015 ist daher, die Komplexität zu reduzieren und einen klaren Fokus auf Serviceintegration, Kunden- und Business-Orientierung zu legen. Die Anzahl der Prozesse sollte nicht weiter erhöht werden. Das sollte sich dann auch in den Schulungen niederschlagen, die vor allem nach Serviceorientierung gestaltet werden sollten. Insgesamt müssen die proaktiven Elemente in ITIL gestärkt werden.

Ohne, die Inhalte tatsächlich zu kennen, zeigt sich meiner Meinung nach, dass in der neuen ITIL V3 2011 Edition die strategische Ausrichtung der IT mit Blick auf Kunden und Business gestärkt wird. Inwieweit trotz konsistenterer Strukturen die Komplexität von ITIL durch neue Prozesse zunehmen wird oder der Reifesprung zum Serviceprovider hiermit einfacher gelingt, bleibt abzuwarten. 

Zum Schluss sei noch erwähnt, dass Lisa Perri von VMware über die Rolle des Service-Catalogues und die steigende Bedeutung in der Zukunft sprach.

Wer das Webinar anschauen möchte, kann dies hier tun.

ITIL V3 2011 Edition - Key Performance Indikatoren (KPI)

Ich habe gerade auf der Website von itSMF International einige interessante Kennzahlen zur neuen ITIL V3 2011 Edition gelesen, welche jetzt Ende Juli erscheinen wird:

• Das Gewicht der neuen ITIL-Bücher steigt von 4,459 kg auf 6,981 kg. Das sind ja gerade mal 2,522 kg oder 57 % mehr
• Die Anzahl der Seiten erhöhen sich von 1343 auf 1959. Wenn ich noch richtig rechnen kann sind das 616 Seiten oder 46 %.
• Das Buch Service Strategy erhält mehr als 200 zusätzliche Seiten, bei bestehenden 264 Seiten - da spare ich mal die Prozentrechnung.
• Die übrigen Lifecyle-Bände erhalten wohl jeweils knapp 100 neue Seiten.  

Das ist doch mal eine Hausnummer - vor allem wenn ich hier diese Sätze lese:

"ITIL 2011 is an update, not a new version....
This update should not affect the tool vendors, any impact will be minor."

Nun gut - über Inhalte ist ja noch wenig bekannt, aber mir scheint es, dass es doch eine ganze Menge Neues gibt...