Festlegung von ITIL als gemeinsames Framework für mehrere IT-Teams auf der ganzen Welt

Mein Manager und ich wurden beauftragt, mehrere IT-Teams in verschiedenen geografischen Regionen (mit mehreren Zeitzonen und unterschiedlichen kulturellen Verständnissen) zu leiten/zu fördern.

Die Teams sind noch nicht erfahren, ihnen fehlt die grundlegende Disziplin beim Testen, Überprüfen und Ausrollen.

Ich dachte daran, eine Methodik wie ITIL aufzusetzen oder Information Technology Infrastructure Librarydie Basis für ein gemeinsames Verständnis zu legen, zB rollt man nicht ohne Test oder ohne grundlegende Kommunikation mit den Benutzern aus.

  • Wäre ITIL dafür ein anständiges Framework?
  • Wenn ITIL nicht das „Ding“ war, gibt es dafür eine andere Methodik?
  • Hat jemand Erfahrungen damit und möchte diese bitte teilen?

Vielen Dank

Bei dieser Frage geht es um IT-Governance und nicht um den Bereich oder die Praxis des Projektmanagements, wie in unserem Hilfecenter definiert.
Hallo @CodeGnome, ich würde ehrlich sein, ich habe mir mehrere Websites angesehen und keine kommt näher als pm SE, um meine Frage zu stellen. Ich wünschte, ich könnte es woanders fragen, aber dies ist bisher der beste Ort. Das tut mir leid.
Hallo, obwohl es hier möglicherweise eine gute Frage gibt, lautet sie derzeit eher "Ich habe ein Tool, wie kann ich es an meine Bedürfnisse anpassen" und nicht "Ich habe ein Problem, was ist das beste Tool, um es anzugehen?"
Hallo @TiagoCardoso, ich habe versucht, eher eine Lösung als ein Problem zu finden. Ich kann eine andere Frage stellen, wo ich es anders formulieren werde ... Was ist Ihre Einnahme ...?
Schreiben Sie diesen einen Kumpel besser um und konzentrieren Sie sich auf Ihr eigentliches Problem. Sobald Sie dies getan haben, kann die Community sie weiter bearbeiten, um sie zu einer fundierteren und wertvolleren Frage zu machen. Beifall

Antworten (1)

Ich bin nicht so vertraut mit den Details von ITIL. Wenn ich darauf gestoßen bin, habe ich normalerweise festgestellt, dass der Prozess die Organisation stagnierte.

Was ich raten würde, ist, die Dinge umzudrehen, anstatt sich in einen großen Prozess zu legen (mit all der Dokumentation, Schulung, Hochlauf usw.), beginnen Sie dort, wo Sie sind, und entwickeln Sie etwas von dort aus. Dies fällt unter die losen Konzepte von Kaizen, beginnen Sie dort, wo Sie sind, was vom Toyota Way stammt.

Hier ist die Gliederung, die ich empfehlen würde:

  1. Absolut nichts tun. Sie sind neu, Sie wissen nicht, wie all diese Teams heute funktionieren. Verbringen Sie die ersten 90 Tage mit Lernen.
  2. Machen Sie einen Gemba Walk (Google den Begriff). Es ist eine andere Sache aus den Toyota Way-Konzepten. Gehen Sie zu jedem Ort und beobachten Sie. Sehen Sie, wie die Dinge laufen. Sehen Sie sich ihre Herausforderungen an. Hören Sie, was sie zu sagen haben.
  3. Do Value Steam Mapping: Identifizieren Sie die drei häufigsten Dinge, die Ihre Teams tun oder tun werden. Legen Sie den Zeitplan fest, um von der Idee bis zur Fertigstellung zu gelangen. Sie suchen besonders nach Wartezeiten, wenn Sie auf jemand anderen warten, und nach „Rückfall“-Punkten, an denen das Projekt in eine frühere Phase (z. B. QA) zurückgeworfen werden kann.
  4. Entscheiden Sie sich für Ihre Ziele. Jetzt müssen Sie entscheiden, wie Ihre Organisation aussehen soll. Erstellen Sie darauf aufbauend Ziele. Diese Ziele sollten „Warum“ oder „Was“ sein, nicht „Wie“. Genug Anleitung, damit die Teams dann den besten Weg finden können, um diese Ziele zu erreichen. Denken Sie daran, dass Ziele messbar sein müssen, oder Sie werden verwirrt sein. „Ist schnell“ ist kein Ziel, „Lieferzeit um 50 % reduzieren“ ist ein Ziel.
  5. Start. Fang einfach an. Erstellen Sie keinen Prozess, gehen Sie nicht ins Detail. Fang einfach an.
  6. Prüfen und anpassen. Jetzt fängst du an, wöchentlich oder sogar täglich zu schauen, wie die Dinge laufen. Optimieren Sie die Dinge, damit sie funktionieren, dokumentieren Sie, was funktioniert, und machen Sie weiter.

Sie sollten sich auch darauf einstellen, dass unterschiedliche Teams mit unterschiedlichen „Wie“-Prozessen enden werden. Wenn sie das „Was“-Ziel erreichen und den Arbeitsprozess dokumentiert haben, dann ist das in Ordnung.