ITサービス管理（ITSM）の過去と未来

ITSM.Toolsブログに掲載されたStuart RanceによるStuart Rains の記事「ITサービス管理の過去と未来」の翻訳を紹介します。



この記事は概要的な性質のものであり、ITSMプロセスの経験豊富な参加者に指示を与えるという事実により、ITSMに没頭する初期段階の両方で興味深い場合があります。



警告：この記事は明確に販売されており、翻訳者の控えめな意見では、不必要に熱狂的な評価が含まれていますが、現実の世界では見られず、脆弱な心に悪影響を及ぼします。



（以下、イタリック体で、翻訳者のメモ。）



1970年代からITサービス管理（ITSM）に携わっており、それ以来多くの変化を目の当たりにしてきました。 これは、ITSMが何であり、今後どうなるかについての私の考えと観察の短いコレクションです。

1970年代の例外的な技術的焦点

ITに関する私の仕事は、70年代後半に始まりました。 私はサポート、機器の復元に携わり、長い間、さまざまなハードウェアとソフトウェアのインシデントと問題を解決する方向で開発しました。 ITで同様の仕事をした他の人たちと同様に、さまざまなハードウェアおよびソフトウェア製品とそれらの復元方法を勉強した多くのトレーニングコースに行きましたが、プロセス、サービス、または顧客との連携に関するプログラムはありませんでした。 「生涯」私が何をしているのかを誰かが尋ねたら、「コンピューターの修理」または「コンピューターの問題を解決する」などと答えます。 当時、私はITSMのことすら聞いたことがなく、もちろん、インシデント管理や問題管理（問題管理）のようなことをしているとは考えていませんでした。

1990年代のITIL

1990年代半ば、ITIL（ITSMを実装するための主要なベストプラクティスのセット）に出会い、それは私にとって啓示でした。 私が知らなかった家族を発見するようなものでした。 可用性管理、サービス継続性管理、変更管理、問題管理など、自分の仕事のアイデアを発見しました。 これで、作業に一貫性と厳密さを追加するために使用できる一連のテンプレートができました。 ITIL FoundationとITIL Service Managerコースに行き、最終的にITILインストラクターになり、これらの素晴らしいアイデアを他の人々に伝えて、彼らがキャリア目標を達成できるようにしました。



当時、ITILはプロセスに最も焦点を当てており、プロセスを作成するための一連のアイデアを提供していました。 ITILを使用し始めた企業では、ITサポートチームは、緊急事態から緊急事態まで、インシデントからインシデントへの移行を停止し、叫んでいる人の量によって問題の重要性を判断しました。 代わりに、サービスレベルと顧客を一致させることにエネルギーを向けました。 その結果、ITILのアイデアを使用して合意したレベルは、反復可能なプロセスの作成に役立つと確信しており、これにより、合意されたサービスが体系的に提供されることを確認できました。

ITIL 2007エディション

2007年に、ITILの新しいリリースがリリースされました。 最大の変更点は、サービスライフサイクルを中心に構築された新しい構造です。 これで、サービスが何であるかを理解しやすくなり、ユーザーにとってのサービスの重要性に重点が置かれました。 戦略（サービス戦略、SS）とサービスの開発（サービス設計）に最大の重点が置かれ、継続的なサービス改善（CSI）に一冊の本が掲載されました。 また、SLAへの準拠は、ITが組織で行う最も重要なことではない可能性があることを暗示しています。 顧客が悲しみ、失望、または激怒している間、SLAを提供することは非常に一般的でした。 サービスへの焦点は、本当に必要なものでした。 ユーザーを抱える顧客を理解し、当社のサービスから真の価値を提供する必要がありました。



そこで、仕事へのアプローチを変えました。



私は一貫した目標を達成しようとし続けましたが、状況が私を強制したとき、私は目標を無視し、顧客が本当に望むものに集中できることに気付きました。 重要なことは、顧客満足度と顧客体験です。 ただし、もちろん、適切な場合にのみこの方法で動作する必要があります。これには、IT組織が最初に成熟したプロセスを持ち、確立された手順とプロセスの再現性に厳密に依存せずに自信を持って作業する経験豊富なスタッフが必要です。



多くの人は、プロセスに焦点を合わせることからサービスに焦点を合わせることが非常に難しいと感じています。 ITSMでは、人々がSLAを順守しなければならないことに自信を持っています。たとえそれが顧客を傷つけたとしてもです。 私はしばしば、そのような人々と一対一で、そしてソーシャルネットワークで話し、非常に昔ながらのプロセス指向のアプローチから離れるように説得しようと試みました。 私は時々成功しましたが、多くの場合、彼らは変更なしで働き続け、あらゆる業界の顧客に問題を引き起こしました。

次は？

一方、ITSMは再び前進しています。 ソフトウェア開発の世界は、アジャイルとDevOpsのアイデアを受け入れてきました。 ITSMコミュニティの多くのメンバーは、顧客により多くの価値を提供するために、さらなる開発も必要であることも認識しています。 ここに、TSMの将来に影響を与えると思うものをいくつか示します。 ここにはすべてのアイデアを詳細に説明する十分なスペースはありませんが、あなたの興味を温め、あなたが自分でもっと勉強できるようになるのに十分だと思います。



アジャイル



アジャイルソフトウェア開発マニフェストは2001年に公開されました。 以下の重要性を強調しました。



-個人とその関係は、プロセスやツールよりも重要です

-動作するソフトウェア製品は、ドキュメントの完全性よりも重要です

-契約上の義務よりも顧客との協力が重要

-変更への反応は、計画に従うよりも重要です



この結果、より柔軟で迅速なアプローチが可能になり、新しいソフトウェアの品質が大幅に向上し、変化するビジネスニーズに迅速に対応できるようになります。



アジャイルのアイデアのいくつかは現在、ITSMに適用されています。 彼らは、ITSMを展開して改善するためのより良いアプローチ（もはやITSMプロジェクトの長年はありません）と顧客をサポートするためのより良い方法（人とその関係はプロセスやツールよりも重要です）の考えを変えました。



無駄のない



リーンは、可能な限り低いコストで顧客に最大の価値を生み出すことの重要性を強調する管理アプローチです。 これについてもっと知りたい場合は、インターネットでリーン生産、リーン製品開発、リーンソフトウェア開発に関する記事を見つけることができます。



ITSMのコンテキストでは、リーンの最も重要な側面は次のとおりです。



-あなたが参加しているエンドツーエンドのバリューチェーンの定義

-すべての行動が顧客に価値をもたらすことの保証

-すべてのアクションで空のコストを排除し、価値を生み出すのに必要な最大限のシンプルさまでプロセスステップを削減します。



自動化



自動化は常にIT管理の一部でした。 私が始めたとき（1970年代後半）でも、可能な限りタスクを自動化しました。 何が変わったのですか？ 自動化を提供および促進するツールが利用可能になりました。 これを行うことにした場合、ほとんどすべてを自動化できます。



プロセス作成の一部として人間の専門知識が必要なため、自動化できないものがいくつかあります。 次の条件を満たしていれば、他にできることはすべて自動化できます。

-私たちは何をどのようにやっているか本当に理解しています

-簡単に文書化できるかなり単純なアクション

-頻繁に起こることと自動化によりますます良くなる

-自動化では、柔軟なルールで人間の評価を置き換えることはできません



Devops



DevOpsは、アジャイル、リーン、オートメーションのアイデアを活用して、開発から顧客へのソフトウェアの移行を改善します。 DevOpsは次の3つの領域を強調しています 。

• フロー/パス -開発を制限するボトルネックを除いて、エンドツーエンドのバリューチェーンでどのように適応するかを理解する
• フィードバック -迅速なフィードバックを提供して、不適切な品質を可能な限り迅速かつ費用対効果の高い方法で特定および排除します。
• 実験とトレーニング -仮定と予測の作成、それらのテスト、研究と改善。

これらの3つの領域と関連チームの集中的なコラボレーションおよび非常に高いレベルの自動化を組み合わせることで、新しいソフトウェアおよび変更されたソフトウェアを非常に迅速に展開/実装し、高い柔軟性とユーザー満足度を実現します。



DevOpsは通常、ソフトウェア開発者が実行するタスクの多くを自動化しますが、開発の運用面は含まれません。

TSMはこれを使用する必要があります。 新しいアイデアの開発を支援し、日常業務の自動化が大幅に増加しても、プロセス全体の評価が損なわれないようにする必要があります。



エンタープライズサービス管理



ITSMの開発およびサポートに使用されるアイデア、ツール、およびプロセスの多くは、非ITサービスのサポートにも役立ちます。 Corporate Service Managementは、キャパシティ管理、人事管理、弁護士、およびサービスを提供する他の部門を含む組織全体に対して同じアプローチを使用します。



私たちは皆、インシデントと問題を管理し、サービスの要求を満たし、顧客と対話する必要があります。 同じツール、プロセス、アプローチを使用して、企業全体のサービスを提供できます。



サービスの効果的な企業管理は、他の部門によるITSMツールの使用だけでなく、組織全体に対するエンドツーエンドの協力とトレーニングの関与でもあります。 多くの場合、IT部門はサービスの提供について多くのことを学ぶことができます。



ITILプラクティショナー



ITILの最新の補充は、2016年1月にリリースされたITIL Practitioner Guidanceです。 この投稿は、このブログで説明されている多くのアイデアをサポートしています。



ITILプラクティショナーは、9つのガイドラインを定めています。

1. 価値に焦点を当てる
2. 人のために働く（経験のための設計）
3. 現在の状態に基づいて（現在の場所から開始）
4. 全体的に作業する
5. 小さなステップで移動（反復的に進行）
6. 使用場所で観察（直接観察）
7. 明確にする
8. 協力する
9. 簡単にする（シンプルにする）

3つのルートコンピテンシーについても説明します。

• メトリックと測定プロセス
• コミュニケーションズ
• 変更管理組織

そして、これはすべて、ITサービスの継続的改善のコンテキストで説明されています。 ITILプラクティショナーの詳細を知りたい場合は、ITILプラクティショナーのマニュアルを読み、トレーニングコースを受講することをお勧めします。 また、私の良き友人であるStephen MannによるITIL Practitionerのレビューもご覧ください。

結論として

ITSMは、IT組織がテクノロジープロバイダーから付加価値サービスプロバイダーに進化するのを支援してきました。 そして、1990年代の方法を使用して21世紀の問題を解決すると、すぐに不十分になります。



ITサービスを提供またはサポートするすべての人は、新しいアプローチと新しいアイデアの採用を使用する必要があります。 彼らは顧客に価値を追加します。



採用について考えるかもしれない概念のいくつかはこのブログで説明されていますが、役に立つ他の多くのものもあります。



私は本当に好きです：

• かんばん -「オンタイム」原則に基づく開発/生産管理方法、
• コビット5-ビジネスの価値を創出するためのIT管理の実践/推奨事項のコレクション、
• Resilia - AXELOS実践的情報セキュリティ管理認証システム

ソーシャルネットワークに関するこれらのトピックの継続的な議論から、さらに学ぶことができます。

• Twitter #ITSM
• Facebook Back2ITSMグループ

それでは、次の組織のイベントに参加してください。

• itSMF
• HDI
• ISACA
• およびその他の組織。

私自身から、ITSMのトピックに関するロシア語のリソースへのリンクをいくつか追加します。

• ウェブサイトitSMF Russia
• FacebookページitSMFロシア
• ClevericsのITSMトピックに関するウェビナーのアーカイブ（ロシアITSMコンサルティングおよびトレーニングのリーダーの1人）
• Clevericsのニュースポータル、実務者のブログ、ITSMディスカッション

以上です。 読書がお役に立てば幸いです。



ご清聴ありがとうございました。コメントに評価を残してください。