IT-Prozesse optimieren – Seminarangebot

Ich freue mich auch in diesem Jahr wieder gemeinsam mit Management Circle das Praxisseminar

Für mehr Effizienz, Qualität und Serviceorientierung:

IT-Prozesse  optimieren

anbieten zu dürfen.

In zwei Tagen sprechen wir über

• Herausforderungen im IT-Prozessumfeld und wie diese gemeistert werden können
• Optimierungskriterien für IT-Prozesse und wie man die richtigen und wichtigen finden kann
• Veränderungsstrategien und man ein angemessenes Umsetzungsprogramm entwickelt
• Veränderungen von IT-Organisationen und wie diese wirklich gelingen
• Erfolgsfaktoren und Methoden im organisatorischen Change Management
• Prozessverbesserungen und wie man Durststrecken vermeidet und Risiken im Griff hat
• Organisatorische Verankerung des Prozessmanagements und die passende Prozess-Governance
• Optimale Prozessdokumentation jenseits der Prozessmodellierung
• Kontinuierliche Verbesserung von Prozessen und die Messung von Prozesserfolgen
• Nutzung von Kundenfeedback für die Prozessoptimierung

Termin:

13. und 14. Juni 2013 in Düsseldorf oder auch gerne individuell als InHouse-Training

Ich würde mich freuen, wenn Sie Interesse an diesen Themen haben und in Düsseldorf dabei sein können.

Alle Informationen finden Sie auf bei Management Circle unter

http://www.managementcircle.de/seminar/it-prozesse-optimieren.html

Change IT – Manage IT: IT-Organisation verändern und steuern

Change IT – Manage IT: IT-Organisation verändern und steuern

Ein Unternehmen muss heutzutage seine Unternehmensstrategien und -strukturen  laufend an veränderten Rahmenbedingungen anpassen und weiterentwickeln. Wandel repräsentiert heute somit keinen Sondervorgang mehr, sondern eine häufig auftretende Regelerscheinung. 

Ich (+Markus Bonk) möchte dieses Thema mit Fokus auf die IT-Organisation gerne aufgreifen und Sie ganz herzlich zur Webinar-Reihe „Change IT – Manage IT" einladen.

In vier einstündigen Webinaren sollen Themen wie:

• Zwischen Plan und Chaos der Organisationsentwicklung in der IT
• Vom Scheitern mit Ansage zur Wirklichen Veränderung
• Überleben in der Matrix – Wenn Prozesse auf Struktur treffen…
• Vom Irrweg PLAN-BUILD-RUN zur echten IT-Organisation für Ihr Business

diskutiert werden und Ihnen effiziente Lösungsansätze aus unserer Beratungspraxis vorgestellt werden. 

Ich freue mich, Sie von März bis Juni jeden zweiten Dienstag im Monat von 10:00 – 11:00 Uhr in unserer Webinar-Reihe begrüßen zu dürfen. Für Führungskräfte in IT-Organisationen ist die Teilnahme kostenfrei.

Change Strategy - Kurs bestimmen:
Dienstag, 12. März 2013 10:00 Uhr bis 11:00 Uhr

Zwischen Plan und Chaos der Organisationsentwicklung in der IT
Strategische Planung organisatorischer Veränderungen in der IT ist notwendig - und nicht aufwändig.
Hier können Sie sich für den Kurs Change Strategy anmelden.

Change Management - Änderungen umsetzen
Dienstag, 09. April 2013 10:00 Uhr - 11:00 Uhr
Vom Scheitern mit Ansage zur wirklichen Veränderung
Effektives Change Management in der IT-Organisation - und Schubladenkonzepte sterben aus
Hier können Sie sich für den Kurs Change Management anmelden.

Prozess-Governance - Abläufe steuern
Dienstag, 14. Mai 2013 10:00 - 11:00 Uhr
Überleben in der Matrix - Wenn Prozesse auf Strukturen treffen...
Prozessmanagement - aber wie? Führen von IT-Prozessen zwischen den Mühlsteinen der Linie
Hier können Sie sich für den Kurs Prozess-Governance anmelden.

IT-Governance - Mehrwert schaffen
Dienstag, 11. Juni 2013 10:00 Uhr - 11:00 Uhr
Vom Irrweg PLAN-BUILD-RUN zur echten IT-Organisation für ihr Business
Irrwege und Auswege zwischen Desorganisation, Komplexität und Nutzenbeitrag der IT
Hier können Sie sich für den Kurs IT-Governance anmelden.

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?