翻訳者から：ITのインシデント管理から企業のビジネスプロセスのインシデント管理へと移行することで、ITが企業内でその価値をどのように高めることができるかについての提案を掲載したStuart Rainesによる興味深い記事。
このアイデアは新しいものではなく、Enterpeise Service Managementとして知られています。 どこにでも適用できるとは考えられませんが、会社の経営陣がITだけでなくITの人員とプロセスに信頼と信頼を持っている場合、それに応じて高いレベルのサービス文化と成熟度があります。 それにもかかわらず、アイデア自体は知って理解する価値があるので、努力する目標としても非常に適しています。
オリジナルへのリンク
2018年1月15日公開 。
難易度 ：エントリーレベル（イデオロギー）
現在、私はクライアントと協力して、ITサービスを管理するためのプロセスとツールの改善を支援しています。 毎回、そのようなタスクに取り組んでいる間、私は学ぶことができることを見つけます。今回は、インシデント管理に対するクライアントのアプローチについて考えることを余儀なくされました。 これは、広範囲にわたる結果を伴う完全に珍しいアイデアです。 私の意見では、他の組織はそれを自分自身に適応させることで利益を得ることができます。
インシデントとは何ですか？
現在、世界で最も人気のあるITサービス管理プラクティスのコレクション-ITILは、インシデントの次の定義を提供します。
「ITサービスの計画外の中断またはその提供の質の低下...」
この定義は高度にIT指向です。 ITILは、インシデントが顧客のビジネスに与える影響を最小限に抑えることの重要性について語っていますが、インシデントはITで行われていると明確に説明されています。 したがって、これは表明されていますが、インシデントを管理するとき、私たちは顧客よりもITについて無意識に習慣的に考えます。
私のクライアントはインシデントの定義を変えています。 事件は
「ビジネスにとって望ましくない結果に向かうビジネスプロセスの製品の逸脱。」
これはまったく異なる考え方であり、その結果は通常とは大きく異なります。 私の観点から、それは人々がインシデントに取り組む現在のインストールよりも潜在的にはるかに効率的です。
誰がインシデントを解決するアクションを提案できますか？
通常、インシデント管理はITの問題に焦点を当てています。 必要なアクションは、インシデントの解決を担当するITスタッフによって提案されます。 ソリューションへの顧客の参加が必要な場合（何らかのアクションが必要）、インシデント管理プロセスの一部のように見えないことが多く、これらのアクションの実行方法とタイミングにITがわずかな影響（または責任）を与える場合があります。 最悪の場合、ITは「カウンターをオフにし」、顧客がインシデント管理プロセスインジケーターの目標値でアクションを完了するまでの待ち時間を考慮に入れなくなります。
インシデントをビジネスプロセスの産物としての逸脱として考える場合、状況は非常に透明であり、逸脱に影響を与える人はインシデントを解決するためにサポートが必要になる場合があります。 ITサービスが中断される理由が何であれ、ITチームのメンバーは積極的に行動しますが、IT内のインシデントだけに集中することはなく、ITが顧客の行動を待っている間、インシデント管理は停止しません。 代わりに、インシデントが解決されるまで、スタッフの行動、結果への統合された影響など、インシデントは引き続き積極的に管理されます。 これは、一見小さな定義の変更が、態度、行動、文化、結果に大きな変化をもたらす可能性があることを示しています。
営業部門の誰かが誤ったデータを会計システムに入力し、顧客がこの会社にお金を借りているというエラーとともに請求書が外部顧客に送信されたとします。 クライアントの定義によると、これは明らかにインシデントであり、サービスデスクサービスに登録する必要があります。 このインシデントを解決するためのアクションは、データを修正することです（低レベルのデータベース操作のためにIT担当者の参加が必要になる可能性があります）。これには、企業の顧客とのやり取りが必要です。 これらは、営業スタッフまたはマーケティングスタッフによって実行されるアクションです。 ただし、誰が、なぜ、どのように実行したかにかかわらず、すべてのアクションは、インシデント管理プロセスのルールとツールを使用して記録、監視、および制御されます。 そして、これは、連続性（シームレス）と一連のアクションという形で、ビジネスプロセスの復元に結果をもたらすはずです。
インシデントをクローズするタイミング
IT従業員は、ITコンポーネントの正常な機能が回復するとすぐにインシデントを解決できると考えがちであり、これによりビジネス結果に逸脱が生じました。 しかし、大きなビジネス上の問題が発生した場合、ビジネスプロセスを通常の状態に戻すために、IT部門は追加の作業を必要とすることがあり、これは必要なアクションの完全なリストになります。
ITILの推奨事項によれば、インシデントがクローズ可能であることを顧客が確認するまで、インシデントは「解決済み」状態でなければなりません。 実際には、多くのIT組織は、顧客が長期にわたって結果に関するフィードバックを提供しない場合、インシデントを自動的にクローズします。
組織は、インシデントのビジネス指向の定義に従って、すべての顧客プロセスのビジネスの逸脱が解消された後にのみインシデントをクローズできるという明確な理解に至ります。 これは、顧客から要求されたすべてのアクションが既に完了しており、すべてが正常な状態に戻ったことを意味します。
作成するインシデントレポートは何ですか？
通常、インシデント管理レポートは、IT組織がインシデントを迅速に解決することに焦点を合わせています。 これは、ITの改善を計画および管理するのに役立ち、サービスレベル契約（SLA）に従って顧客に対する義務がどの程度満たされているかを示します。 しかし、ビジネスにとっては、このようなアプローチには実質的に価値がありません。
インシデントをより「ビジネス」オプションに再定義すると、ビジネスにとって価値のあるレポートを作成する可能性が高くなります。
- ビジネスプロセスにおけるマイナスの影響はどれほど重要でしたか？
- インシデントの最も一般的な原因は何ですか？ （多くの場合、ITの問題はそれとは無関係です）。
- インシデント解決の最大の遅延はどこですか？
これらのデータはすべて、ビジネスの管理方法の計画と管理に役立ちます。 そして、ITがビジネスにどれほど役立つか。
おわりに
ITインシデントを厳密に解決するITデスクサービスがありますか？ たぶん今は、インシデントの定義を拡張することで、ビジネスプロセスの製品の規範からの逸脱を含め、インシデントの原因を考慮せずに、組織により大きな価値を生み出すことができると考える時です。 これはすべて、ITが組織全体のビジネスにより深く関与し、事業成果を達成する真のパートナーと見なされるのに役立ちます。サービスユニットの機能のみを実行し、故障を修復するだけの場合とは対照的です。
画像ソース： miningcamper