Reading Time: 1 minutes
この記事の所要時間: 約 8分

当連載記事について

当連載記事では、ITIL®の研修を多く手掛ける専門家が、分かり易い口語体でより実際的な観点からITIL®を解説しています。サラッと読みながらもITIL®に基づいた考え方をより実践的なレベルへ落とし込むことができます。また、ITIL®に準拠するための機能を備えたITサービスマネジメントツール「ManageEngine ServiceDesk Plus」を提供するゾーホージャパンより、欄外コラムとしてツールの詳細や関連機能の説明を行います。ITIL®の概念を把握しつつ、ツールを活用した場合のイメージを広げる際の一助となりましたら幸いです。
※ITIL® is a Registered Trade Mark of AXELOS Limited.

 

はじめに

今回で4回目を迎えるこの連載。1回~3回までは歴史だとか用語の説明をしていたので、物足りないと感じていた方もいらっしゃるのではないでしょうか。今回からやっと少しずつ実務に関係する内容になってきます。なので、飽きずにもう少しお付き合いください。

顧客成果

今回の記事では2つのテーマを話します。「顧客成果」と「品質」です。そのうちのまずは顧客成果から。

顧客成果というのは、顧客が目指しているゴールになります。例えば、皆さん、お金を払って電車に乗ることがあると思います。この場合、お金を払っているので皆さんは顧客です。そして、電車を使用して移動させてもらうことは、鉄道会社が提供する鉄道サービスというものを使用しているということになります。この時の顧客成果は何でしょうか?おそらく、「(移動した先で)何らかの用事を済ませられる」というのが答えになります。具体的には、移動先で仕事するとか、デートするとか。これが顧客成果です。

これをITに当てはめると、例えば、会社で支給される携帯とかスマートフォン。なぜ、会社がお金を払ってまで携帯やスマートフォンを社員に支給するのかというと、社員が素早くコミュニケーションできるようになることで「業務の効率化が図れる」、「時間が節約できる」とか、あるいは営業がお客様とフレキシブルに連絡を取れることで「営業の機会ロスを減らせる」などのメリットがあるからでしょう。この、「業務の効率化」、「営業の機会ロスの低減」などのメリットが顧客成果になるわけです。

顧客成果の取り込み方

では、この顧客が考えている顧客成果を、ITIL®はどうやってITサービスに取り込もうとしているのでしょうか?実際にはいろいろなタイミングや手段で取り込むことにはなると思いますが、ITIL®が考えるオーソドックスな取り込み方を第二回目の記事で使用した図を使って説明したいと思います。まず使用する図はこちらになります。

関連するフェーズはサービスストラテジ(SS)とサービスデザイン(SD)。そして、関連するプロセスはBRMとSPM、そしてサービスデザインの各プロセス。代表としてはDCになります。

<サービスストラテジにあるプロセス>

・BRM(事業関係管理)
・SPM(サービス・ポートフォリオ管理)

<サービスデザインにあるプロセス>

・DC(デザイン・コーディネーション)

※()は正式名称。

これらのフェーズやプロセスがどうやって顧客成果を取り込むのか説明します。まず、サービスストラテジにあるBRMは顧客の要望を把握します。この時に要望の背景や経緯も把握します。先ほどの例でいうなら、顧客が「今度社員に携帯電話を支給しようと思うんだよね」と言っていたとします。それをBRMが聞きつけた。するとBRMはあわせて携帯電話を支給して何をしたいのかも聞いてくる。「携帯を支給することで業務の効率化を考えている」とか、「営業がお客様とフレキシブルに連絡を取れるようにすることで営業の機会ロスの削減を狙っている」とか。要望の背景や経緯も把握すると、おのずと顧客が狙っている顧客成果が把握できるようになります。

次に、把握した要望、背景、経緯を参考にしながら、携帯電話やスマートフォンを貸し出す(もちろん貸し出したら通話やインターネット、テザリング機能が使える)というITサービスを、サービス・プロバイダとして新たに導入するかどうかを決めます。もし携帯電話貸出サービスは既にあって、スマートフォンの貸出を追加する必要があるのであれば、既存サービスに対する改修をするかどうかを決めるのでしょう。逆に、既にあるサービスが不要だということを聞いてきたのであれば、サービスの廃止を考えるかもしれません。

これらサービスの新規導入、変更、継続、廃止等を決めるのがSPMというプロセスです。そして、SPMは新規導入するサービス、変更するサービス、継続するサービス、廃止するサービスをサービス・ポートフォリオという一つの文書にまとめて、次のフェーズであるサービスデザインに引き継ぎます。ここまでがサービスストラテジの話。

次に引き継いだサービスデザインではどのような活動(プロセス)を行うかというと、サービスデザインなので設計をします。ただ、サービスデザインには8個のプロセスがあるので、そのプロセスがそれぞればらばらに設計すると収拾がつかなくなります。そこでDCというプロセスがサービスデザイン全体をコーディネートしながら設計していくんです。

だから、SPMから引き継がれたサービス・ポートフォリオは、最初にDCで受け取られる。このDCは各サービスデザインのプロセスにサービス・ポートフォリオ(もしくはその中身)を連携する。そして、連携されたサービス・ポートフォリオを元に、サービスデザインの各プロセスは設計活動を行っていくということになります。こうして顧客が目指すゴールである顧客成果は、顧客の要望としてITサービスに取り込まれていくことになります。

品質ってなに?

次に、今回の記事の2つ目のテーマである品質についてです。品質は「災害や障害に強い」「壊れにくい」とか「使いたいときに使える」とか、先ほどの鉄道サービスでいうなら「電車が時間に遅れにくい」とか「天候に影響されづらい」とか「乗り心地がよい」ということになります。

そして、この品質は顧客成果の達成に関係してきます。どういうことかと言えば、例えば、ある鉄道サービスが「台風の中でも予定通りに電車が運行できる」という品質を持っていたとします。この品質があれば、顧客は台風の中でも電車で恋人のもとに向かえます。仕事であれば、台風が来ていてもオフィスに行くことができ、溜まっていた仕事を済ませることができる(実際には台風の時くらい会社を休みたいので電車が動いている方が迷惑かもしれませんが・・・)。

というように、災害対策という面での品質が非常に高く、台風でも運行できるという品質を持っていたら、顧客は恋人に会いに行くことができたり、仕事ができたり、他にも移動した先で用事を済ますことができるかもしれない。これはつまり、お金を払って電車に乗っている顧客の成果を達成しやすくしているということになります。だから品質が高いと顧客成果を達成しやすくなり、品質が低いと顧客成果の達成は遠のくということになるのです。

ITIL®が目指しているのは品質の向上です

次に、ITIL®はこの品質をどうやって向上させていくのかというと、まず、「品質を向上させたいと思っているのは誰なのか」という話から始まります。品質の向上を望んでいるのは当然顧客になります。そして、品質が高いか低いかを判断するのも顧客です。さらにいうと、ITIL®は顧客が高いか低いか判断する品質というものは、一定ではないとも言っています。

例えば、顧客Aが電車に乗りました。冬場であれば暖房が効いた車両を求めるでしょう。夏場に乗れば車内が熱いのでクーラーの効いた車両を求めるでしょう。さらに同じ夏場でもお腹の具合がよくないとなれば、クーラーがよく効いた車両は避けたいと思うかもしれない。というように、同じ顧客であっても時期、時間、タイミング等のシチュエーションによってサービスに求めてくる品質は変わります。場合によっては一緒にいる人や行先によっても、サービスに求める品質が変わります。とにかく顧客というのは気まぐれで、求めてくる品質は一定ではないのです。

だからITIL®ではどう言っているかというと、「そんなのには付き合っていられない」というのではなく、「気まぐれだけど、この気まぐれに付き合わないと、顧客から価値のないサービスとみなされて、そっぽを向かれかねない。だから、サービスを供給しているサービス・プロバイダは常に顧客が求めてくる品質に合わせてサービスを向上させていきましょう」というスタンスをとっているんです。まじめですね。

とはいえ、顧客が求めている品質というものが常に変わり続けるというのであれば、サービス・プロバイダはなかなか把握ができません。それにそもそも顧客が求めている品質が顧客の気まぐれで変わるのあれば、品質が顧客の期待通りであるかどうかの判断も顧客本人でないとわかりません。

よって、ITIL®ではサービスの品質について指標を用いて測定することにして、この指標を事前に顧客と合意することにしました。この指標はサービスレベルといわれるもので、サービスの達成度を表すものです。

例えば、鉄道サービスで遅延率というサービスレベルを設けたとします。この遅延率は、一定期間のうちに何回電車が遅延したかを表します。1年間で2回の遅延が発生したら、2回/365日×100≒0.54%となり、0.54%の確率で遅延したということになります。3回に増えれば、0.82%。4回なら・・・。当然、この遅延率は低い方がサービスの品質が高いということになります。

そして、サービス・プロバイダはこのサービスレベルをもって、顧客と事前の合意を行います。勝手に決めたら顧客は納得しないですからね。例えば「今年の遅延率は0.5%以下にする」とかです。この合意した遅延率をサービスレベル目標値といい、そのサービスレベル目標値が書かれ、顧客との合意に使われた文書をサービスレベル合意書(SLA)といいます。

そして、このSLAに書かれたサービスレベル目標値を元に定期的にサービスを測定します。測定した結果、サービスレベル目標値を満たしていたら問題なし。サービスレベル目標値を満たせていないことがわかれば、満たせるように改善を進めます。このようにサービスレベル目標値やSLAを元に品質を把握して維持・改善していく活動がSLMというプロセスになるわけです。

なお、鉄道サービスを例にサービスレベルを説明しましたが、携帯電話の貸し出しというITサービスを例にした場合は、エリアカバー率などがサービスレベルに相当することになるでしょう。

最後に

次回は、「顧客起点での要望や品質が決まったとは言ってもさ、サービス・プロバイダだって生活がかかっているんだよ!」という話ですね。それではまた次回。

>>記事一覧:ITの品質向上とコスト削減からとらえたITIL®

執筆者情報

日本クイント株式会社 コンサルタント 吉村友秀(よしむら ともひで)
主要資格:ITIL® エキスパート、公認情報システム監査人(CISA)

 



ServiceDesk Plusの「サービスカタログ管理」機能

連載コラムをご一読頂き、ありがとうございます。ManageEngineでは、ITIL®準拠のためのITSM機能を網羅した「ServiceDesk Plus」というツールを提供しています。

今回、記事の中でサービスの新規導入、変更、継続、廃止等を決定するプロセス「SPM(サービス・ポートフォリオ管理)」が紹介されていました。ServiceDesk Plusは、このSPMに関連する機能として、「サービスカタログ管理」機能を備えています。

企業/組織でITサービスの内容が既に定義されている場合、以下のようにServiceDesk Plusの「サービスカタログ」として登録し、一元管理できます。

この時、「インターネット」というカテゴリひとつを取っても、ユーザが必要とするサービス内容は「接続不具合への対応」から「Wifiの設定」、「VPNアカウントの作成」など、多岐にわたるでしょう。このため、ServiceDesk Plusでは、下図のようにカテゴリ毎のサービス一覧を登録できるようになっています。

登録したサービスは、下図のようなリクエストフォームと連動しており、ITIL®で言うところの「サービス要求管理」も簡単に実施できるようになっています(詳細は、別のコラムでご紹介します)。

例えば、「外出が多い営業部メンバーにはスマートフォンを貸与する」というサービスが開始された場合、上図のようなサービス要求フォームを作成し、サービスカタログとして公開しておくことで、営業担当者にとっても依頼先が明確になりますし、事情を知らないシステム課メンバーが突然の依頼に戸惑うこともありません。

なお、第3回の連載記事コラムでは、ServiceDesk Plusの「グループ管理」機能をご紹介しました。当機能を活用すれば、役職、部署、サイトなどを基準としたユーザのグループを作成できるのですが、さらに「特定のグループにのみITサービスを公開する」という風に、サービスカタログ機能と連動させることもできます。

今回の例の場合、「営業部グループにのみスマートフォンの貸出サービスを公開する」という設定にしておくことで、全く関係のない部署のメンバーが勘違いをして申請してくるという事態を防げます。

本日ご紹介した機能は、ServiceDesk Plusの評価版から30日間無料で利用できます(技術サポートも付きます)。

とは言え、「手探りで評価している暇はない」「もっと簡単に説明を受けたい」という方は、「訪問依頼窓口」や「オンライン相談」制度もご利用ください。

その他、下記の情報もぜひご利用ください。

<製品について情報収集したい方>

<製品について質問したい方>