現在地

第4回 サービスレベル管理とは?(後編)


サービスカタログとSLA

今回は、架空の小売店(XYZスーパー)を題材にして、「サービスレベル管理(Service Level Management)」を中心に紹介する。

月島にあるXYZスーパーでは、最近、駅前にコンビニエンスストアが開店したり、デリバリ形式のお弁当屋さんがオフィスビル内に進出したり 等、小売業の競争激化の影響を受けている。そのため、XYZスーパーの販売部門では、他社との差別化戦略として魅力的なポイントカードの発行を決定した(ポイントカードは、スイッチングコストがかかるため、利用者の囲い込みには有効であると判断)。
この事業戦略に沿って、XYZスーパーの販売部門では、ポイントカードシステムを開発するためのIT予算を確保し、ポイントカードサービスの開発プロジェクトを立ち上げた。

ポイントカードサービスの開発プロジェクトイメージ

上図を見て欲しい。XYZスーパーのIT部門(ITサービスプロバイダ(以下、ITSP))が管理しているサービスカタログ(*1)を表記している。図を見ると分かる通り、サービスカタログには現在提供中の「21.仕入先管理サービス」「22.POS サービス」が含まれているが、それに加えて「23.ポイントカードサービス」が新たに追記された。

*1:ITSPが提供しているサービス(一部、準備中も含む)一覧をカタログ化したものを「サービスカタログ」という。今回のケースのように、予算の承認がおりた段階でサービスカタログ上に反映される。

これらのサービスカタログを最新の情報に維持管理する活動が、サービスカタログ管理のプロセスの役割である。これにより販売部門では、サービスカタログを通じて新規サービス開発の進捗具合を適宜確認することができる。

一方、新規サービスの依頼者である販売部門のマネージャと、開発・提供側のIT 部門(ITSP)のマネージャの間で、ポイントカードサービスに対するサービスレベルと両者の責任を明確にする必要がある。

通常、ポイントカードは、スーパーの営業時間内にしか使用されない。
そのため、販売部門からみると、以下のような要件が想定される。

  • XYZスーパーの営業時間(平日10:00~20:00、土日祝日10:00~22:00)は、ポイントカードサービスが利用できることを保証してほしい
  • 障害発生時には1 時間以内にサービスを回復して欲しい

これらの要件をサービスレベル要件(SLR:Service Level Requirement)という。

サービスレベル要件イメージ

販売部門の販売員も、ポイントカードサービスの使用手順を遵守すること、IT 部門(ITSP)が想定していないような使い方をしないこと、定期的な計画保守時間を確保すること 等について約束をし、責任を負わなければならない。

このように、販売部門とIT部門(ITSP)の両者のサービス品質における合意事項が、サービスレベルアグリーメント(SLA:Service Level Agreement)である。SLAは、双方の果たすべき責任を定義するもので、けして一方的な要求の押し付けであってはならない。
また、事業戦略によりサービスレベル要件(SLR)は常に変化する可能性がある。一度合意したSLAを遵守するだけの運用では、顧客に対して価値のあるITサービスを提供できているとは限らない。SLAの遵守状況を監視するだけではなく、SLRに応じてSLAの内容を交渉していくことも、サービスレベル管理のプロセスの役割である。SLAの交渉に関しては、次回のコラムでも、ゲーミフィケーションのワークショップ内容と共に紹介する予定だ。

プロアクティブな対応

SLAでは、可用性やキャパシティにフォーカスすることが多い。例えば、SLAの話題としてよく引き合いに出される「ファイブ・ナイン」とは、「9」が「5つ」連なる可用性「99.999%」を示している。

前回のコラムで紹介した「プロアクティブ」であるが、これはサービスレベル管理だけではなく、可用性管理やキャパシティ管理等の他のプロセスでも同様に用いられている。その名の通り、可用性管理とは、可用性を設計するプロセスであり、キャパシティ管理は、キャパシティ項目(性能や容量 等)を設計するプロセスである。

第2回のコラムでも紹介したが、サービスのIHIP特性のひとつとして「消滅性:Perishability」という特性がある。これは、「サービスは、モノと異なり、保存しておくことができない。」という特性である。サービス提供側から見ると、事前にサービスを作り置きすることが難しいことを示唆しており、そのため、あらかじめ需要を予測してITサービスのキャパシティを設計する必要がある。(現在の需要ではなく、将来的な需要を見越して、プロアクティブに対応する必要がある)

以下に、プロアクティブなキャパシティ管理の対応例として、Twitter Japanの事例を紹介する。

Twitter Japan

https://twitter.com/TwitterJP/statuses/363494742518013952

2013年8月2日(金)夜に、国民的人気アニメが地上波テレビで放送されたが、放送タイミングとあわせて、毎回恒例となっているTwitter上での「バルス祭り」が勃発した。上図のTwitter Japanの公式ツイートにもある通り、これまでの最高である2013年の「あけおめ」ツイート33,388を大幅に上回った。(物語のシーンに合わせて、時刻は午後11時21分50秒。ツイート数は、14,3199TPSという大幅な記録更新。)

ITmediaニュースより

「“バルス祭り”その時Twitterの中の人たちは──日本と米本社をまたいだ舞台裏」
http://www.itmedia.co.jp/news/articles/1308/06/news057.html
TPSの集計は、米国本社の限られたエンジニアが担当する。そのため日本の広報は“バルス祭り”の約2週間前には祭りの予定をエンジニアらに連絡し、TPSの集計を依頼した。前回のバルス祭りで急激に負荷が増えたことを覚えていたエンジニアらは、その後のサーバ増強により、急激な負荷増加にも耐えられると請け負ったという。

上記のニュース記事にもある通り、将来的な需要を見越してプロアクティブに対応した結果、事前にサーバ増強等の対策を施すことで、Twitter Japanは、バルス祭りを乗り越えることができた。また、将来的な需要を見越すためには、顧客とITSPの間で定期的なコミュニケーションが必要である。この辺りは、キャパシティ管理や可用性管理だけではなく、サービスレベル管理も顧客との橋渡しの役目を担っている。(*2)

*2:キャパシティ管理と連携して需要を予測するプロセスは「需要管理」であるが、本コラムでは、顧客とのコミュニケーションを行う上で「サービスレベル管理」も引き合いに出している。

前回のコラムでは、サービスレベル管理の1つめのポイントとして、「モニタリングおよび報告」を紹介したが、それは結局のところ、顧客とのコミュニケーションとリンクしている。また、ITILコア書籍では、サービスレベル管理は、「信頼性のあるコミュニケーションチャネルと関係を戦術レベルで提供する」とあるが、これも同様のことを指しているといえるだろう。

例えば、「来月に店舗で30%OFFのキャンペーンやるよ。Webサイトにも関連情報を掲載するよ。」という情報を顧客から得ることで(コミュニケーションをとることで)、ITSPは、必要に応じてプロアクティブに対応(インフラ増強等)することができる。

さいごに

筆者は、研修講師という職業柄、多くの受講生(ITサービスに関わりのある)と接する機会があるが、意外にも顧客と「SLA」を締結している受講生(プロジェクト)の数はけして多くはない。
「SLA」の重要性を認識していても、それを実践することは別の問題である。特に、企業文化や慣習等の事情もあり、会社によっては「SLA」締結のハードルは思いのほか高いところもある。

そこで、次回は、「SLA」の合意・監視・報告の一連の流れを、ゲーミフィケーションのワークショップを通じて紹介する(座学形式ではなく、ゲーミフィケーション形式で実際に体験する)。