２００７年５月１１日に作成された、バージョン３の用語集(v3.1.24)に基づいて要求実現と訳されているこのプロセスは、バージョン２にはなかった新しい概念です。個人的には要求実行と訳したいこのプロセスは、頻度が高くリスクの小さいユーザからの要求を、インシデント管理や変更管理と分離して管理するという発想に基づいています。
消耗品交換などのサービス要求をインシデントの一種とみなし、プリンタの移動要求は変更要求でサービス要求ではないと考えるバージョン２のアプローチは、実務に携わっている人ほど実感しにくい概念でした。
この件は、本エッセイの第９話（インシデントの定義）などでも取りあげています。
情報や助言を要求するサービス要求、日常的に発生する手順の確立した変更要求、苦情や意見への対応は、インシデント管理や変更管理と分離して考えた方が、よりシンプルに管理されるであろうというのがバージョン３の発想です。
要求実現の最終目標は次のようなものです。
既に定義され認可された標準サービスを、ユーザが要求し利用するためのチャネルを提供する。
サービスデスクに求められる多くの要求は頻繁に繰り返されます。逆に言えば、要求を満たすための手順、担当する人やグループ、目標とする時間の尺度やエスカレーションの仕組みを前もって検討することができるのです。
組織としあらかじめ手順を作成し認可していれば、より効率的に質の高い対応をすることができます。この仕組みが要求モデルです。ＩＴ組織は予測される要求に対する要求モデルを作成し、要求実現の効率化を図ります。
