Part2　ビジネスの観点からIT組織のBehaviorはどうあるべきか？

Part1では，ITサービスマネジメントと，そのベストプラクティスである「ITIL」の概要を紹介しました。では，ITILの考え方では，IT組織のBehavior（振る舞い）はどうあるべきなのでしょうか？Part2では，この点について解説しましょう。

　まずは，次の事例を読んでみてください。

　製造企業A社で，ある日重要な取引先から連絡があり，発注したはずの商品が期日までに指定場所へ納品されていないことが判明しました。

　連絡を受けたIT部門は，早速原因の究明に着手。社内システムの記録やログを調べた結果，「取引先から発注データを受け取っていなかったことが原因」と結論付け，すぐに取引先にその旨を連絡しました。結果的にIT部門としては，SLAを守ることができました。

　翌週，IT部門の部長は，毎月実施している社内顧客（ビジネスオーナー）との「SLAレビュー・ミーティング」で，SLAの目標を達成したことを報告しました。同時に，「EDIで発注データを受け取れたかどうかの確認が甘かった」ことを指摘し，今後同様な問題が発生した場合に備えて，確実にシステム上の詳細なログとジョブの履歴を確認できるようシステムの一部を改善することで，社内システム側の障害と社外で発生した障害の切り分けを可能にする仕組みを構築するよう，社内顧客に提案しました。

　この提案に対して，社内顧客からは異論が出ました。「新たに投資して，詳細なログやジョブの履歴を確認できるようにしたところで，本当に会社としてのビジネス目標の達成につながるのか？」というわけです。「取引先に自社のシステムが正しいことを証明しても取引先の満足度を向上させることにはつながらないのではないか」というのが，社内顧客の主張でした。

　最終的に同社は，システムへの投資は最小限にとどめ，同様なトラブルが発生した際に一刻も早く商品を届けるための仕組み作りを検討することにしました。同時に，在庫の引き当てから取引先への発送に至るステップをスムーズに実行できるようシステムを変更するかどうかも検討することにしました。社内顧客は，今後発生するかもしれない同様のトラブルが与えるビジネス上の損失と費用に基づいて，投資判断を行ったのです。

　さて，製造企業A社のIT部門のBehavior（振る舞い）は，ITILの考え方として正しかったのでしょうか。検証してみましょう。

　まず取引先から「発注したはずの商品が期日までに指定場所へ納品されていない」という連絡がありました。システム的なインシデントという意味では，「取引先からEDIの発注データを正しく受け取れなかった可能性がある」ということになりますが，ビジネスの観点で言えば，インシデントは「取引先が発注したはずの商品が期日までに指定場所へ納品されていない」ことにほかなりません。

　Part1で述べたように，ITILの「インシデント管理」の第一の目的は「ビジネスの迅速な復旧」です。もちろん，EDIシステムに異常があって，今後もビジネスへ悪影響がある場合は，システムの復旧が最優先です。

　しかし，社内システムの記録やログを確認して，「社内システムには障害がなかった」と取引先に回答できるようにしたところで，取引先が発注したはずの商品を受け取れないことに変わりはありません。真っ先にすべきことは，一刻も早く商品を届けることなのです。

　ITILの考え方に則れば，トラブルがシステム障害によって引き起こされたのかどうかは，緊急対応で取引先に商品を届けた後で，ゆっくりと時間をかけて調査すればよいのです。調査の結果，システムに不具合があることが分かれば，ITILのプロセスの一つである「変更管理」を行い，安全確実に変更作業を済ませて，同じような不具合が再発しないようにする，という流れになります（図1）。

図1●製造企業A社がとるべきだったプロセス

[画像のクリックで拡大表示]

　製造企業A社は，最終的に，在庫の引き当てから取引先への発送に至るステップをスムーズに実行できるよう，システムを変更するかどうかを検討することにしました。ここで重要なポイントは「あくまでもビジネスの観点でシステムを変更するどうかを判断すべき」ということです。

　例えば，システム変更に膨大なコストがかかる場合は，システムを変更せずに「同様なトラブルが起きたときに取引先が不満を感じて他のメーカーに切り替えてしまう」というリスクを受け入れるのも一つの判断でしょう。システム変更にコストがかかっても，取引先の満足度向上を最優先に考えてこの変更に投資する，という判断もあり得ます。つまり，ITILでは，“ビジネスの観点からの判断”が必要不可欠で，IT組織にもその感覚が求められるのです。

　ビジネスの観点から正しく判断しコストを正当化するためには，IT整備計画に基づいた正しいIT予算の管理が行われていることも必須となります。IT組織として，正確な財務情報を提供できていなければならないわけです。上の例で，仮にシステム変更を行うとしても，年間のIT活動の優先順位が明確にされていれば，「いつ実施するのか」，「実施できるのか」，「予算の範囲内で可能なのか」といった判断を下しやすくなります。その結果，予期せぬコスト増大によりキャッシュフローを悪化させたり，本来実行することになっていたプロジェクトを中止するといった，ビジネスへの悪影響を回避できます。

　これらをまとめると，製造企業A社のIT部門がとるべきだったBehaviorは，以下のようになります。

　ITILの冒頭でも，「ITこそがビジネスである」そして「ビジネスはITそのものである」と述べられています。IT組織がITとしての都合だけを，社内顧客がビジネスの都合だけを考えていたのでは，あるべき姿のITサービスマネジメントは到底実現できません。ビジネスオーナーとIT組織が協力して，ビジネスの観点で最良の選択・判断をしていくことが求められるのです。