ITサービス管理の未来

IT サービス管理 (ITSM) は長い間存在してきましたが、IT マネージャーは「IT サービス管理 (ITSM) はどこから始めればよいのか」という重要な質問をしています。

[[347039]]

Boomi のグローバル エンタープライズ マーケティング ディレクターの Myles Suer 氏は、2005 年に Peregrine Systems に入社したとき、Peregrine Service Manager の組み込みデータベースが非リレーショナルであることに驚いたと述べています。 Peregrine は、IBM が DB2 を市場に投入する数年前の 1981 年に設立されました。 1989 年に ITSM が導入され、英国政府の ITSM と ITSM の多くの概念が明確に更新されました。 IT インフラストラクチャ ライブラリ (ITIL) 自体もいくつかの更新が行われています。たとえば、Suer は ITIL 第 3 版のレビュー担当者です。昨年リリースされたバージョン 4 は、ITSM を DevOps、アジャイル、リーン作業方法と簡単に統合できるように設計されています。問題は、ITSM はどこから始まるのかということです。これはスーアーが提起した疑問です。

パブリック クラウドの使用と DevOps は ITSM をどのように変えているのでしょうか?

• 「ITSM を導入する最大のメリットは、全員が共通の言語を話せるようになることです」と CIO の Rick Osterberg 氏は述べています。 「クラウド/DevOps 環境では、P1 インシデントと P4 サービス リクエストの違いを全員が理解する必要があります。」
• CIO の Joanna Young 氏もこれに同意し、次のように述べています。「ITSM の基礎は今でも重要です。ITSM システムの実装について話し合う場合、これらは優れたガイダンスと基盤になると思います。ITSM をデリバリー プロセスに組み込むことで、継続的な運用サポートに関する会話を促進/推進できます。」
• 最高情報責任者のキャリー・シューメーカー氏もヤング氏に同意している。彼女は、「すべてのコンポーネントと依存関係を理解することは依然として重要です。また、大規模なイベントでは、プロセスを確立し、コミュニケーションをとることが重要です。最後に、変化は今も起こっており、それは依然として刺激的です」と述べました。
• 「ITSM を実施する場所や方法の詳細は変わるかもしれないが、中核となる概念は変わらないと思う」と CIO の David Seidl 氏は言う。 「DevOps では、アジャイルに必要なのと同じ種類の変更が必要になる可能性があり、別の変更を行うときにも再度変更が必要になります。行うすべてのことが DevOps であると想定されていますが、多くの場合、そうではありません。代わりに、多くの場合、ITIL やその他のハイブリッド/コンポーネント化されたモデルのように、組織内のコンテナーとして DevOps を使用します。」

DevOps が ITSM の様相を変える

• Seidl 氏は、DevOps が ITSM の様相を変える可能性があると主張しました。 ITSM のチケット発行の側面は依然として存在するかもしれませんが、それが提供するプロセスと、機能が展開される方法と場所のガバナンス構造はより軽量になります。
• 「私たちはサーバーの無秩序な拡大から VM の無秩序な拡大へ、そして今度はクラウドの無秩序な拡大へと移行しました」と CIO の Jason James 氏は述べています。 「ベンダーからわかりにくい請求書が届いた場合、ITSM を効果的に活用して部門間のリクエストと承認を調整し、クラウド リソースの使用状況を把握することができます。ITSM は、ユーザーが内部監査を実施する際に役立ちます。」
• 最高情報責任者のアイザック・サコリック氏は異なる見解を示している。同氏は、「サービスデスクは主にエンドユーザーコンピューティングを扱っていました。しかし、デジタルトランスフォーメーションによってテクノロジー/データビジネスが重要になるにつれ、サービスデスクの重要性は高まるばかりです。コロナウイルスのパンデミックをきっかけに、ITSM が重要になりました。」と考えています。そうは言っても、サコリック氏は、変更管理は変革管理の一部になる必要があるとアドバイスしています。さらに、構成管理データベース (CMDB) は常に混乱しており、クラウドのエラスティック コンピューティング、サーバーレス、SaaS を考慮すると、現在ではほとんど維持不可能になっています。これを念頭に置いて、サコリック氏は次のように述べた。「ITSM は、ユーザーに権限を与え、アプリケーションに関する支援を提供し、実装や選択が不十分なテクノロジを補う必要があります。」
• 「DevOps はデータと人材を活用して問題を解決します」と Splunk の CIO である Andi Mann 氏は述べています。 「今日、ヘルプデスクは記録システムになっています。」

それでも、Forrester の ITSM/DevOps アナリストである Charlie Betz 氏は次のようにアドバイスしています。

（１）デスクトップサポート（エッジコンピューティング／エンドユースコンピューティング）は常に存在します。

（２）情報管理は大規模なデジタル化にとって重要な課題であるが、構成管理データベース（CMDB）はこれまでその問題の解決策となってこなかった。構成管理データベース (CMDB) が有用であるかどうかという質問に対して、有用なサブセットがいくつかあります。

（３）変更管理は主要な自動化プロセスとして維持される必要がある。

（4）変更諮問委員会は必須ではなく、他の場所で調整が行われる場合は廃止することができます。たとえば、Scrum of Scrums の議題の常設項目になる場合があります。

歴史的に、ITIL は ITSM を個別のプロセスに分割しました。より体系的な見方が必要でしょうか?

• 「ITSM は近代化する必要がある」と CIO の Jason James 氏は述べています。 「クラウド サービスを含め、必要に応じてより高度なセルフ サービスを実現するには、自動化をさらに進める必要があります。さらに、すべてのワークフローは応答性をサポートし、不要な承認や遅延を排除するように設計する必要があります。AI 主導の ITSM の必要性はありますが、実現にはまだ道のりが残っています。」
• Seidl 氏は、「私は常に ITIL を、必ずしも完全に異なるサイロではなく、便利な言語として見てきました。概念と実装の現実は、これらが曖昧であることを意味します。言語は、私たちが行動するときに目標に近づいていることを保証するためのハンドルとして機能します」と述べています。
• 「それはやはり言語の問題だ」とオスターバーグ氏は語った。 「バックエンドに関係なく、停止、より深刻な問題、変更、トランザクション要求など、すべてが交差して重複しています。これらすべてを説明する共通言語が必要です。」

ITIL は複雑すぎますか?

• Sacolick 氏は、ITIL では物事が複雑になりすぎ、用語やプロセスが多すぎると考えています。今日のツール、特に統合された DevOps、Agile、AIOps により、インシデント サポートが大幅に簡素化されます。アジャイルはスケールアップとは何の関係もありません。それは文化と考え方の問題です。組織は、アジャイル チームが自己組織化できる場所と、どのような標準が導入されているかについて、十分な情報に基づいた決定を下す必要があります。そのため、同氏は「ITSM はクラウド コンピューティングの世界の主要な問題に焦点を当て、セルフサービスを正しく導入する必要がある」と述べています。
• ジェームズ氏は次のようにアドバイスしています。「ITSM は高度に自動化され、モバイル化されている必要があります。現在、多くの ITSM 機能はボットで実行できます。これには、パスワードのリセット、デバイスの構成、基本的な Q&A が含まれます。これらを自動化することで、サービス デスク チームはより複雑な問題に集中できます。多くの既存の ITSM ソリューションには、まだこれらの機能が欠けています。チャットボットは、効果的に実装されていれば、保留状態になったり、人間と話したりするよりもはるかにリラックスできます。昨年、Amazon と何度かやり取りしましたが、そのたびにボットを介して行われ、質問するたびにすぐに回答が返ってきました。」

ITSM に他に何が含まれているかについても、さまざまな回答がありました。

• 「ITSMには、問題、変更、サービス要求、資産、サプライヤー、構成に関するマスターデータ管理と統合プロセスが必要です」とヤング氏は述べた。しかし、ピット氏はリストを「事件、問題、変更、要望」に絞り込んだ。 CIO の Carrie Shumaker 氏は、物事をより総合的に捉え、「変更はインシデントにつながり、それは継続します。統一要因はサービスであり、場合によっては構成管理データベース (CMDB) 要素であると考えています」と述べています。
• 変更管理に関して、ベッツ氏は次のように述べています。「問題は、変更管理を変更諮問委員会 (および場合によっては承認) と同一視していることです。CAB は非効率的で、リズムが制限され、同期的で、対面式の専用コミュニケーション チャネルです。調整の問題を解決するには、もっと良い方法が必要です。」
• それでも、CISO の Michael Oberlaender 氏は、「価値創造/バリュー チェーンに重点を置いたエンドツーエンドのコンセプトを追加することが絶対に必要です。ITSM では、十分な価値を追加しないことが数多く行われています」とアドバイスしています。

ITSM において、消費可能なデジタル ビジネス サービスのカタログは幅広い役割を果たしますか?

• 「一部の組織では、その通りです。重要なのは、組織、その目標、その能力に合ったコンポーネントとモデルを選択することです」とザイドル氏は語った。 「ITSM の導入に失敗する組織が増えている一方で、ITSM をうまく機能させる方法を見つけ出す組織も増えています。」
• 「それは組織が ITSM をどのように定義するかによって異なります」と CIO のマーティン・デイビス氏は述べています。 「その範囲は、IT 関連の問題やサービスの解決を支援することに限定されるべきでしょうか、それともそれよりも広いでしょうか。境界はどこにあるのでしょうか。ビジネスが進化し、IT が進化するにつれて、組織が強い規律とビジョンを持っている場合、カタログは適切なアプローチです。断絶があり、すべてに例外がある場合、問題が発生する可能性が高くなります。これを成功させるには、組織はプロセス指向の企業である必要があります。」
• ヤング氏も同様の意見を述べ、「それは可能です。しかし、多くの組織にはそれを実行する能力も余裕もありません。彼らにとって、DevOps とアジリティはまだ初期段階、あるいは希望リストにすぎません。問題は、特に中小企業向けに、ベンダーがどのような道筋を提供しているかです。」と述べました。
• 同様に、ジェームズ氏は、「ITSM は進化し、より多くのシステムやクラウド サービスと連携して、より多くのサービスを提供しながら、より多くの洞察と応答性を提供する可能性が高い」と考えています。しかし、サービス カタログは API と消費可能なビジネス サービスのカタログになるのか、という未解決の疑問が残ります。
• 「IT チームは、SOAP からマイクロサービスまで、さまざまなテクノロジーを通じて、利用可能なデジタル ビジネス サービスのカタログを開発しようとしてきました」と Sacolick 氏はアドバイスします。 「簡単な方法がない限り、大規模には実現しないと思います。」

結論

明らかに、より多くのワークロードがパブリック クラウドに移行するにつれて、IT 運用の多くの側面が変化しています。 ITIL と ITSM はそれほど違いはありません。多くの CIO は、ITIL と ITSM がさらに多くのことを実現する機会があると考えています。今後 5 年間で、ITSM はさらに変化します。

Constellation Research の Dion Hinchcliffe 氏は、ITSM は DevOps とうまく連携するように進化する必要があり、今後も進化していくだろうと述べています。これは、SaaS、パブリック クラウド、シャドー IT を含むすべての IT テクノロジーを網羅することを意味します。これは、ITSM が選択と競争を可能にしながら、アクティブなサポートおよび管理ネットワークになることを意味します。そうすることで、潜在的に拡張可能なサービス カタログの概念を含む、可用性の高いアプローチが実現します。