なにしてみよっか

サービスってなんだろな?を細々と。基本マニアックなネタが多いです。トヨタ生産方式を信奉してます。某製造業の営業と社内SEをやってました。

ITIL4を深掘ってみる(2/5)-1.プロセスがプラクティスに変わった理由

こんにちわ。

 まず最初にお詫び2つ。

1.前回投稿から半年を超えてしまいました。かなり遅くなり申し訳ありません。

2.第一回目のなかでITIL v2にはプロセスしかない、というようにとらえられる表現をしていましたが、正確には、3P「Process」「People」「Product」の3つはありました。当時からプロセスだけではありませんでした。この場で訂正いたします。*1

 ですが、ITILv3になってから、プロセスにフォーカスるするのではなく、他にも目を向けるべしという話と方向性はズレないので、このまま進めます。

 

 さて、早速ですが、プロセスがプラクティスに変わった理由を考えてみたいと思います。

 前回、要約すると下記のようなことを書きました。

ITILv2のプロセス偏重主義から、ITIL4になるとプロセスの占める割合は1/8まで低下した。

 そもそも、プロセスとは何でしょうか?

 プロセスとは、「処理」です。

 例えば、インシデント管理プロセスは、日本語に翻訳すれば、「インシデントを管理する一連の処理」と翻訳することができます。

 ITILを語るうえでプロセスは外せません。そしてそれを説明するためにはITILの歴史が重要になってきます。

 ITILの最初(通称、ITIL v1)については、日本語化されていませんし私自身が知らないのでお話しできることはないのですが、ITILv2当時、開発と運用という2つの考え方でどの(How)ように運用に渡せば運用側は気持ちよく(これには、適正な人的、金銭的コストで引き受けられるのかということを含みます)システム運用を引き受けてくれるのか?という観点で整理され、どのような手続きを経ればそれが達成されるのか?という考えで書かれました。ゆえに、プロセスが非常に大事でした。

 具体的な処理(プロセス)を経れば、開発から運用にシステムを引き渡すことができます、とシンプルに定義したわけですね。

 

 それに対して、ITILv3は、ITSMを成功させるための主要な4要素として、4Pを誕生させます。「People(人材)」「Product(ツール)」「Process(プロセス)」「Partner(協業企業)」として定義してプロセスは、ITSMを成功に導く(この成功の定義が、ITとビジネスを整合させ統合することを目標としたサービスライフサイクルアプローチ)1つの要素である、と初めて定義しました。

 ITをビジネスにおいてうまく使う、つまり、ITILv3の言葉で言えば、ITとビジネスを整合させて、統合することを考えた際、プロセスだけでは整合性は取れないし統合もできないと宣言したわけです。

 ちょっと具体的に考えてみましょう。

 例えば、インシデント管理プロセスで考えてみましょう。*2

  • ユーザから「何か壊れた」という問い合わせをエージェントがコールシステムで受け付けた。受け付けた際、かかってきた電話番号から相手を特定した(Product)
  • エージェントは、当該ユーザが過去どのような問合せをしてきているのかをシステムで確認し(Product)、話術スキルと傾聴(People)で話を聞くとPCに関するトラブルであると理解した。資産管理システムで対象PCの修理履歴や今のステータスをで確認する(Product)
  • 資産管理システムで取得できた情報を送りPCの保守ベンダ(Partner)エスカレーションして、プロセスに基づいて機能するインシデント管理システム(Process/Procuct)に対応履歴を残す。

 ……いや、まぁこんなに綺麗な仕組みやリッチなツールがそろっているかって話は置いておいて。。(遠い目)

 このように、いくらプロセス*3定義しても、ツールが整っていなければ、解決に時間を要しますし、情報収集にも時間がかかるでしょう。PC保守ベンダと契約していなければユーザの困りごとは解決できない事例です。さらに、このエージェント氏の傾聴スキルは、サービスデスクとして必須のスキルですし、そういったスキルセットを定義しておかないと、こっちのペースで話して、こっちのペースでフォローしてしまい、ユーザの満足度は上がりません。

 このように、ITをサービスととらえたときにプロセスだけ整えても適正なサービスは維持できない。素直に考えれば当たり前とは思いますが、こういった背景を踏まえて、プロセスの有用性は認めつつも、プロセスを最大限生かすためにも必要な要素をちゃんと整備しましょう、という発想になったのだと思います。

ここまで書いて、やはり気になるので。本筋と異なるので、ここに脚注として余談を記載します。*4

そして、ITIL v3では本来的に4Pだったものの、管理プロセスとしての意味合いから、すべての管理単位をプロセスと定義した。結果、プロセスは構成要素の一つだったのに、プロセスに集中的にフォーカスされてしまった。

これらの反省を踏まえ、ITIL4では、4Pの発展形として、4つの側面(直訳すれば、Four Dimensions。よって、今後4Dと呼称します)に進化。「組織と人材」「情報と技術」「バリューストリームとプロセス」「パートナーとサプライヤ」となりました。つまり、今まで4Pとしていたものがより、検討すべき要素が増えた。

そこで。あえて再度、インシデント管理プラクティスを考えてみましょう。

  • ユーザから「何か壊れた」という問い合わせをエージェントAがコールシステムで受け付けた。受け付けた際、かかってきた電話番号から相手を特定し、当該ユーザが過去どのような問い合わせをしてきているのかを確認。(情報と技術)
  • 過去の問い合わせから、このユーザは自らの状況を語る事が不得手であり対象エージェントとはアンマッチであるとAIが警告(情報と技術)、エージェントAは、ここまでの情報をインシデント管理システム(バリューストリームとプロセス)に登録。
  • AIがエージェントをスイッチするようコールシステムで切り替え(組織と人材情報と技術)。
  • 対話スキルに強みのあるエージェントB(組織と人材)が話を聞くとPCに関するトラブルであると理解した。資産管理システムで対象PCの修理履歴や今のステータスを確認。(情報と技術)
  • 資産管理システムで取得できた情報を送りPCの保守ベンダ(パートナとサプライヤ)エスカレーションして、プロセスに基づいて機能するインシデント管理システム(バリューストリームとプロセス)に対応履歴を残す。
  • ここまでの対応履歴は、ITSMツールでAIがモニタリングしており、SVに対して面倒なユーザの対応にエージェントBが取り掛かっていることを発報。(バリューストリームとプロセス)
  • このユーザに対して問い合わせサービスの利用料金が閾値を超えたことを確認。このユーザの所属する顧客組織に対して、サービスレポートを送付することを決定(バリューストリームとプロセス)
  • 続く…

とまぁ、こんな感じになります。つまり、プロセスで検討する範囲が増えた上に、ITIL4から生まれた新たな概念である、「共創(原文:Co-creation)」を行うためには、契約を含めても全てを可視化していく必要があり、プロセスというキーワードで管理単位を決めても全く「名は体を表さない」状態になってしまう。処理の手順だけを定義しても、ツールがないと全体的な管理はできず、現場の疲弊度合いもわからない。ユーザのスキルセットに合わせた体制の定義もできず、ナレッジにない情報を問い合わせる先もわからない。そんな状態では、まともな「問い合わせ受付・対応」サービスは成り立ちません。

とはいえ、ここまでリッチなサービスをいきなり開始できるわけもない。だからこそ、4Dでどこに対して重点的に投資を行い、サービスを開始するのかを決めていく必要がある。そしてこれらの要素をゼロから作るわけにはいかない。無駄です。だからこそ、先人達のナレッジを4Dで定義した「プラクティス」と言う管理単位に名前を変えた。

 

私としては、そう理解しました。

*1:あまりこのような表現はあれなのですが、自分がITILの師と仰ぐ方の一人からのご指摘。この年になっても指摘していただけるという関係は感謝しかありません

*2:正確に言うと、インシデント管理プロセスを思い浮かべつつ、それをフロー化するのが正しいのですが、これは余談に記載します

*3:しつこいようですが、実体としては、プロセスを基本設計ととらえ、その基本設計に基づき動作するようにフロー/詳細設計に落とし込むのです。詳細は下記余談参照。

*4:余談です。

このプロセスとフローを一緒くたに語っている書籍や人が非常に多いことが気にかかります。このITSM業界の端っこで飯を食わせていただいてそろそろ10年になります。そろそろ自らの経験と責任において、生意気を言うことをお許しください、先達、同僚、後輩。当たり前のことを当たり前に語りますが。

プロセスは処理でフローは流れです。

大事なことなのでもう一度言いますが、プロセスは処理であり、フローは流れです。プロセスは、処理を定義したものであり、フローは定義されたプロセスに基づき、「誰」が「いつ、またはどのタイミングで」「何をする」かの流れを決めてサービスに携わる人間が理解しやすくするために可視化したものです。

具体例で説明すると。

変更管理プロセスは、変更管理プロセスであって変更管理フローではないのです。極言すれば変更管理フローが単独で存在してはいけません。変更管理を経なければいけない作業が存在するので、変更管理プロセスが必要というだけです。

したがって、「変更管理が必要な作業を統合的に管理するフロー」の中に「変更管理プロセスによって定義された「変更管理フロー」が存在します。フローとプロセスの関係性をあえて図にすれば、下記のような感じになります。すべての企業(特に株式市場に上場している企業)の情シスのみなさん(過去の自分を含め)、ホントわかってます?なんか理由あると思うんですが、ここをふわっとした状態にして管理してる組織めちゃくちゃ多いぞ。

プロセスとフローの関係性

余談終わります