【ITSM】#1:インシデント管理

社会人になってから、なんだかんだとITSM:IT Service Managementに関わることが９年ほどになりました。9年前はまだまだ認知されていない分野でしたが、IT化が進み、DXがトレンドになり、この分野も注目され普及してきたように思えます。また、ツールとしても、ServiceNowを筆頭に、AsanaやServiceDesk Plusなど多くのリリースもされてきたと思います。

そんな中でよくある社内導入のためのポイントをまとめてみようと思います。
なお、わかりやすくするために、多少のオリジナリティを加えている箇所はありますので、資格試験などの参考にはならないことをご了承ください。

本記事は、インシデント管理についてです。
ITSMといえば、まずはここが入り口として導入するところが多いはずです。

まず、インシデントとは何か。
よくある誤解として、インシデント＝システム障害 or セキュリティ事故関連　という人が多いようです。それはある意味で正解なのですが、インシデントはもっと広い意味の定義であります。
広義のインシデント、狭義のインシデント　という分類をしています。
広義のインシデントの中には、
・問い合わせ：XXシステムの使い方がわからないので教えてください。
・システム障害：XXシステムが動かなくなりました。直してください。
・インフラ障害：ネットワーク/サーバーに接続できなくなりました。直してください。
などなどです。
障害系が狭義のインシデントになりますね。
問い合わせの類もインシデントになるのです。ユーザが使えなくなった理由は様々です。
マニュアルの場所がわからない。
マニュアルを見ても自分の画面と違うからわからない。
ユーザーアカウントがない。
パスワードを忘れた。
…なんでも理由になりえます。
とにかくユーザ視点で何かしらITが使えなくなった状態になった時、インシデントが発生した、となります。

ということで、こういったあらゆる角度で発生した状態を、
いかに早く安く品質高く解決し、ユーザがITを使える状態にすることがインシデント"管理"に求められていることです。

では、そのようなことを実現する手段としては、
・サービスデスク設置
・ナレッジ管理
・SLA管理
・問題管理
などが挙げられます。
また、新しいものが出てきましたね。これらは別記事で詳細を説明するとします。

インシデントにいろいろな角度があるように、それを解決する手段もまたいろいろある、ということですね。
今まで何もやっていなかった場合、いきなり全てを導入しようとすると現場が混乱してしまうかもしれません。段階的に導入することをお勧めします。

まずは、どういうインシデントがどれだけ発生しているか、を把握するところから始めるべきかと思います。現状把握しないと、改善のしようがないからです。
ITの保守運用が大変です。。というだけでは何も始まりません。何が原因で大変なのか？人が足りないのであれば何名分足りないのか？といったことを定量的に可視化していかないと、予算を取ることもままなりません。

ここまできたら、あとはITSM/ITILのフレームワークに則って、プロセスを構築し、運用していくのみ、となります。
が、特に日本企業は今までのやり方の延長線上を考えることが多いため、ダイナミックな変更には反対勢力が多くついてきます。
フレームワークは、過去多くの企業の実績から得た選りすぐりの要素を集めたベストプラクティスをもとにしているのだから、たった1社の文化・実績が勝てるわけがない、というのが持論です。
そういう意味で、なるべくフレームワークに合わせてオリジナリティは減らしていく方向で進められるとベストです。今がこうだからこうしてもらわないと困る、という現場の意見もあるでしょう。ただし、それをすり合わせて作り込んでいくよりも、この分野はフレームワークに合わせるためには、現場やプロセスをどう変えたらいいか、を議論した方が後々効果的なことになってきます。無理やりねじ込むことはしない方がいいです。
そういう意味で、ITSM導入するよとなった時には、まずはITILのコンセプトや考え方から説明をし、フレームワークを理解してもらい、それに合わせるためには…というストーリーを持って展開していくべきかと思います。いきなりプロセスやツールの話をするなんて言語道断ですね。

フレームワークは便利ですが、それだけでは何も進められないし、効果的ではないものです。ただし、先人の知恵・巨人の肩に乗るといったコンセプトを最初に理解して、進められるかは結構大きなことだと思っています。
上手く利用し、社内の理解を得て導入推進していくことをお勧めします。

以上