ビジネスを変革や成長させるために、ITサービス管理を効率化する具体的な事例集であるITIL。今回は、ITILの5つのフェーズのうち、「4.サービス運用」の「要求実現」を見てみましょう。

サービス運用や管理の事例集 ITILについて知ろう：ITILの基本（1）
https://un4navi.com/management/19007/

要求とは？要求実現とは？

ITILでいう「要求（以下、一般名詞と区別するために「サービス要求」と表記）」とは、ユーザから寄せられるITサービスに対するさまざまなリクエストです。サポートや情報提供、調達など、インシデントにはならない依頼のことです。以前は、インシデント管理の一環で扱われていましたが、サービスの稼働に直接影響するインシデントとは性格が異なるため、ITIL ver.3以降は別に分けて管理するようになりました。また「要求実現」とは、これらのユーザから寄せられるサービス要求を管理し、実現させるプロセスのことです。一般的に、サービス要求はサービスデスク（ヘルプデスク）と関連付けられます。

◯サービス要求の例

• パスワードの再発行やリセット
• サービスの操作説明やヘルプ
• ソフトウェアのインストール
• 新規スタッフのためのパソコンの配備
• メールアドレスの発行
• データベース情報の変更や抽出　など

なぜサービス要求を管理する必要があるのか？

小規模だったり短期間で終わるプロジェクトだと、サービス要求をシビアに管理する必要性はないかもしれません。しかし、プロジェクトや組織の規模が大きく、関係者も多いと、膨大な量と種類のサービス要求が押し寄せます。これらを、無条件にそのままシステムに登録していては、収拾がつかなくなります。
また、ユーザは、解決したい課題を自分で正しく理解し、言語化できているとは限りません。業務内容やサービスへの理解、ITリテラシーなどがさまざまに異なるユーザを相手に、真のニーズを正確に把握し、判断する必要があります。
例えば、ユーザから『サービスが使えない！』と、システム運用担当者にサービス要求が来た場合、原因や理由がいくつか考えられます。そのユーザがサービスに不慣れだったり、ITリテラシーが高くない場合は、具体的な操作方法を教えたり、ヘルプや操作マニュアルへのリンクを示せば解決します。
また、そのユーザにはサービスの機能にアクセス権がなく、エラーが出ている可能性もあります。この場合、そのままアクセス不可にしておくのが妥当ならその説明が必要ですし、新しい業務のために設定の変更が必要になったのかもしれません。これは別の「アクセス管理」プロセスへと引き継がれます。

もし、サービスが停止していたことが原因だったなら、これはサービス要求ではなくインシデントになり、「インシデント管理」プロセスへと引き継がれます。

複数のユーザから、使い方について何度もサービス要求が来るようなら、そのサービスが非常に使いづらいのかもしれません。開発要件は満たしていたものの、ユーザの真のニーズに応えられていなかった可能性があることを意味します。

このように、サービスの要求実現では、サービス要求の中身を判断し、別のプロセスへ引き継いだり、重複があれば統合し、プロジェクトを成功させるために不可欠なプロセスです。

＜PR＞現場の人材不足・スキル不足に悩んでいませんか？SaaS型の統合運用管理サービス「UOM」を導入すれば、システム運用全体がシンプルになって負担も減るので、ユーザからの要求実現の余裕も。詳しくはこちらへ

サービス要求実現の処理ステップ

サービス要求に限らず、ITILに関わるさまざまなプロセスを、統合的に管理できるサービスがあり、大まかな流れは以下の通りです。現時点では人による処理も必要ですが、近い将来、BOTやAIの導入による自然言語解析の精度が上がり、負担が減ることが期待されています。

1.サービスカタログからサービス要求を選択

サービスカタログとして登録された情報から、ユーザがサービス要求を選択します。問い合わせアラートが、Webフォームやメール、監視ツールなどから届きます。
フォームなら、プルダウンメニューやチェックボックスなどで選択式にして整理したり、入力する単語から判断してFAQをリアルタイムにアップデート表示することで、ユーザの自己解決へとつなげる方法もあります。チャットによるリアルタイムコミュニケーションも有効です。言語化が難しい場合を考え、スクリーンショットの静止画やビデオが併用できると便利です。

2.サービス要求を起票

サービス要求をチケットとして管理します。ユーザが入力した情報以外にも、管理に有効となりそうな補足情報を添えておくと、解決までのトレースがスムーズです。

3.判断と承認

担当者宛に承認依頼の通知が自動送信され、サービス要求を処理するかを判断します。内容が、サービス要求なのか、それ以外かなども判断し、処理する担当者（たち）や日付などが割り当てられます。

4サービス要求実現の実作業

各担当者が実作業に取り掛かり、作業記録を残してステータスを更新しながら進めます。

5.クローズして終了

一連の作業が完了したら、サービス要求のステータスをクローズに変更して終了します。必要に応じて、ヘルプやマニュアル、ナレッジにもアップデートを反映させます。

サービス要求に関する一連の情報は「構成管理データベース（CMDB : Configuration Management Database）」に登録されます。ITILの各プロセスである「インシデント管理」「問題管理」「アクセス管理」「イベント管理」「変更管理」「構成管理」などが統合的に管理されているので、サービス要求の更新も即座に連携します。

サービス要求はユーザからのメッセージ

サービス要求では、ユーザのニーズを正しく把握することが第一歩。ユーザとシステム運用、開発と運用で情報共有するためにも、言語化・文章化して記録しステータスを管理することが、ユーザの満足にもつながります。
クレームが来るよりも深刻なのは、何のリクエストもなく、いつのまにかそのサービスが使われずに放置されてしまうこと。サービス要求とは、ユーザがそのサービスに対して関心を持っていることを示すメッセージだともいえます。サービス要求の内容を判断し、言語化されていない行間の真意を汲み取り、整理する。プロジェクト全体を俯瞰して影響範囲を考え、予算やスケジュールのバランスを考える。そして、開発や営業、保守などと調整を重ね、何とかユーザに受け入れてもらえる解決策を探っていく―地味ですが、これもまた重要なシステム運用業務の一つです。

＜PR＞ITILの要求実現というユーザからのリクエストは、運用サイクルに重要。チケット化や履歴の自動管理以外に、システム運用全体をすぐに効率化できる「UOM」を、一度試してみませんか？詳しくはこちらへ