ITILは実装する価値がありますか？
ServerFaultの「システム管理者ジョブのJoelテスト」の質問 から、会社がITILを使用する方が良いとは誰も言っていません。実際、ITILについては誰も言及していません。
ITILは流行ですか？面倒すぎて実用的ではありませんか？ ITILがうまく機能するには、特定のサイズである必要がありますか？
「インシデント」と「問題」のITIL定義は興味深いものですが、ペースの速いヘルプデスク環境では、組織は2つを区別することが本当に役立つと感じていますか？
絶対に。 ITILは、手紙に従わなければならない10の戒めのセットではありません。
それは、単に基盤またはフレームワークから操作するためのものです。
本当の問題は通訳にあります。 ITILを実装よりも回避が容易になるレベルに引き上げると、ITILは機能しなくなります。しかし、適切に実装されると、ITサービスのレベルが上がり、システム管理者のストレスが減ります。
ITILを独断的に実装する人は誰でもばかです（そして彼らは「公式の」ITILコースでそれを私に言いました）。
あなたはそれの一部をあなたのニーズに適応させ、採用することができます/想定されています。変更管理、リリース管理などのさまざまな「領域」間の会話のほとんどが実際には1人の頭の中で行われる場合、1人のIT担当者がITILを実装しようとするのは、明らかに厄介ですが、スケールのもう一方の端、MicrosoftまたはHPの内部ヘルプデスクマネージャーまたはAppleまたは誰でも、ユーザーとヘルプデスクコールセンターがいたるところにいる人に幸運を提供した場合、どうすればよいでしょうかおそらくITILやガイドラインに似たものなしで仕事をするのでしょうか？
この時点で、ヘルプデスクにインシデント管理と問題管理を実装し、それがhas非常に役立ったことを付け加えておきます。
ITILはオン/オフの決定ではありません。環境に関連するものを徐々に展開し、組織で最も摩擦や痛みを引き起こす領域に取り組みます。
例：ヘルプデスクがリクエストに圧倒されている場合は、それらの分類を開始し、ソースを分析して、状況を緩和するためのアクションを決定するのに役立ちます。
これは、実際には、組織で機能することが証明されている一連のベストコモンプラクティスとルールにすぎません。
ITILについて私が最も気に入っているのは、他の企業のITプロフェッショナルと話すときに使用する共通言語を定義していることです。これは、ヨーロッパの多言語多文化環境ではなおさらです。 .。
問題管理、問題管理などが理解され、同じ意味です。
それに加えて、私はロバート・モイアに同意します：ITILを独断的に実装する人は誰でもばかです
ITILはツールです..あなたの救いではありません。
私の経験では、ITILは、サポートスタッフとITスタッフがビジネスからの不当な要求に対抗し、「迅速な修正」や「今すぐそれをクールにしたい」ではなく、テクノロジーの問題に対する実際のソリューションを実装できるようにするフレームワークでもあります。 「」要求。
私は、ITが実装しようとしたほぼすべての標準（ハードウェア、ソフトウェア、認証システム、ストレージシステムなど）を破壊、バイパス、またはオーバーライドする言い訳として「ビジネスサービスの変更」を使用した組織で働いてきました。その会社は失敗し、サポートモデルでITILを生きて呼吸している会社に買収されました。
私は新会社に移行しました。ITスタッフの生活が向上するだけでなく、長期的には、安定した環境が得られるため、ビジネスはより幸せになります。また、の標準が定義されているため、より良いサポートと新しいテクノロジーがより速く得られます。定義された技術標準にフィードするサポート。標準がアップグレードされると、アップグレードパスが何であるかがわかり、展開されたシステムの非常に広い範囲に適用できることがわかります。これにより、そのパスに沿ってはるかに速く移動できます。
私たち[〜＃〜] do [〜＃〜]ビジネスユニットやさまざまなアプリ開発者が「特別な」機器やサービスをリクエストできるようにするためのプロセスはまだありますが、チャージバックを行うため、これは非常に重要です。それを要求する人にとっては予算的に「高価」です。 ITILフレームワークはあなたに
ええ、でも、組織の手順とサポート要件をよく見てみませんか。マネージャーやユーザーと、お金のトレードオフを行う必要がある場合にどのようなサポートレベルを期待しているのかを話し合ってください。次に、これとあなたの仕事をするために使用される手順を文書化します。実際に行ったことは、これらすべてのITIL/ISO関連のものと同じです。
ITILのような標準を知っていると、タスクを完全にカバーするために尋ねる適切な質問をもたらすフレームワークがあるため、上記のタスクが簡単になりますが、最も重要なことは次のことに関するドキュメントです。
- 必要なもの
- なぜそれが必要なのですか
- 誰のために必要ですか
- いつ必要ですか
- 要件を所有しているのは誰ですか（責任があります）
ドキュメントを（単一のタスクのように）最下位のエンティティに分割することは膨大な量の作業ですが、それを実行するとすぐに、手動で実行された大量のタスクが不要であるか、自動化できるか、委任できることに気付くでしょう。 。
組織を徹底的に厳しく観察することは、決して人気がなく、簡単に行うことはできませんが、不必要なことをやめ、タスクを低賃金に委任するだけで、会社の理解が深まり、収益性が向上します。レベル。
本当に不人気になるのは、この種の標準化を行うと、多くの管理レイヤーはそれ自体のためにのみ存在し、それらを削除するとコミュニケーションとパフォーマンスが向上する可能性があると誤って説明することがよくあるということです。
ITILのアイデアは非常に理にかなっていますが、残念ながら、私の経験では、サポート/運用スタッフがビジネスサービスの変更を乗り越えて速度を落とすことができるツールであることがよくあります。