2012.7月号7.14.indd

Size: px

Start display at page:

Download "2012.7月号7.14.indd"

えのあんさい
4 years ago
Views:

1 IT サービスマネジメントフォーラムジャパン

2 会員寄稿 Service Request Management 改考 ~ サービス要求管理システムの構築とビジネスサービス要求の統合 ~ はじめに I. ITIL におけるサービス要求の位置付けサービス要求の扱いは ITIL V3 において要求実現プロセスの管理対象としてインシデント管理から切出されたしかしながらインシデントと同様にサービスデスクで受付け分類され処理されていくという従来の手続きから大きな変更が強調されている訳ではなく要求実現という対応手続きの区分が示されたに留まっているという印象である一方技術動向としては例えばプライベートクラウドの普及に伴いクラウドサービスの利用申請がサービス要求のメニューに飾られる時期を迎えている従来のサービス要求はパスワードリセットのようなインシデントの一種のような概念だったが最早売るべきサービスを提供するものととらえるべきである ITIL において従来サービス要求はインシデントと同様もしくはその一種としてインシデント管理のインプットとなり一部を除き共通のプロセスを経て対処されるものとされてきたが両者の違いについて整理しておこう I.1 ITIL におけるインシデントとサービス要求 ITIL V2 においてサービス要求はインシデントの一種 ( インシデントの中で IT インフラストラクチャ側の障害にあたらないものサービスサポート / OGC) と定義されていたし ITIL V3 においてもインシデント管理のフローチャートにはインシデントと同様に識別記録されカテゴリ化の結果サービス要求に分類された場合は要求実現プロセスに分岐される形で説明されている ( 図 I-1) 本稿ではこの積極的に売ることを意識すべき時期を迎えたサービス要求の管理についてサービス要求管理プロセスを IT 基盤上に実装した幾つかの経験を踏まえインシデント管理との重複部分も含めて純粋にサービス要求を管理するという観点から改めて考定するまた ITIL で述べられるサービス要求は IT サービスの要求をターゲットにしたものであるが ITSCM が BCM を下支えするようにビジネスサービスの要求とそれを下支えする IT サービス要求の位置付けでサービス要求管理をとらえビジネスサービス要求を含めたサービス要求管理への統合について考察する *ITIL is a Registered Trade Mark of the Cabinet Offi ce. 図 I-1. インシデント管理におけるサービス要求 / 要求実現のイメージ 5

インシデントを IT サービスに対する計画外の中断または IT サービスの品質の低下サービス要求をユーザが IT 部門に提出するさまざまな要求一般として分類するものの両者は同様にサービスデスクなどで受付けられ必要に応じて担当者に割当て / エスカレーションし対応が進められるものとして描かれている只この対応の部分はサービス要求ではサービス個々に手順化されているため

3 インシデントを IT サービスに対する計画外の中断または IT サービスの品質の低下サービス要求をユーザが IT 部門に提出するさまざまな要求一般として分類するものの両者は同様にサービスデスクなどで受付けられ必要に応じて担当者に割当て / エスカレーションし対応が進められるものとして描かれている只この対応の部分はサービス要求ではサービス個々に手順化されているためインシデント管理のような共通のフローではなくサービス個々の手続きとして要求実現プロセスとして別に括り出された格好になっているのである I.2 インシデント vs サービス要求 ITIL V3 ではサービス要求をユーザが IT 部門に提出するさまざまな要求を一般的に示すものと説明され用語の定義には例えばパスワードのリセットや新しいユーザに対する標準的な IT サービスの提供など (ITIL V3 用語集 /OGC) といった記述がある昨今の技術動向からはこの要求の中にはサーバ仮想化技術を用いたプライベートクラウドのサービス提供を依頼するような形で例えば新規システムのデモ環境として仮想サーバを 1 ノード貸し出して欲しいといったケースのための利用申し込みがサービス要求のメニューに並ぶようになっているこれらはパスワードのリセットのように当然のごとく無料になっているサービス要求の価格付けについて改めてサービス要求は有料であることを気付かせる良い機会でもあるここでインシデントとサービス要求について価格に限らず主要な違いを整理しておこう表 I-1 のようにサービス要求にはユーザ自身が識別できることによるメニュー化価格の明確化申込みの完全なセルフサービス化というインシデントにない特徴があるこのようにサービス要求が価値対価を伴ってきている点ユーザ自身によるメニューからの申込み機能をもったシステム化が進んできている点などから ITIL V2 で言えばサービスサポートの範疇を出てサービスデリバリとしての色合いが強くなっていると言える表 I-1. インシデントとサービス要求の比較 II. Service Request Management の観点と業務フロー ITIL V でサービス要求に対処するプロセスがインシデント管理プロセスから切り離されたがその名称は筆者に限らず少なからぬ ITIL 利用者が想定していただろうサービス要求管理 (Service Request Management 以下 SRM とも ) プロセスではなく要求実現プロセスであった確かに図 I-1 で示されるようにインシデント管理から分岐して要求実現に向かうインタフェースは ITIL V2 から説明されており要求実現として括り出した方が一貫性の点で説得力があるしかしながら本稿では I.2 でまとめたようにインシデントとサービス要求の違いを意識した上でサービス要求の発生ポイントである要求申請即ちサービス要求の申請をプロセスの開始としてクローズまでのサービス要求のライフサイクルをサービス要求管理としてまとめたい II.1 サービス要求管理と要求実現 ITIL V3 の要求実現は ITIL 2011 Edition においてサブプロセスに分解されたプロセスフローや個々の記述が強化されており今後それとの比較において説明したい時期ではあるが本稿では現時点で普及している ITIL V3 (2007) の記述を踏まえて筆 6

4 者の SRM システム構築経験からサービス要求に関わる業務フローモデルを整理しておきたいこのモデルのスコープはインシデントから分類された後の要求実現のプロセスではなくサービス要求を申し込むところから始まるもので大きくはビジネス組織 (=IT 利用組織 ) に割当てられる要求申請の活動群とサービスデスクなど窓口における要求受付の活動群サービス提供組織 (=IT 組織などサービスプロバイダ ) に割当てられる要求実現の活動群によって構成される図 II-1 に示したように要求申請の活動を視野に入れてこれら全体を示すにはその一部にあたる要求実現プロセスではなくサービス要求管理プロセスと呼ぶのが相応と考えられる A B C SR SR SR SR: 図 II-1. サービス要求管理プロセスのフロー II.2 サービス要求管理のサブプロセスと活動 II.1 にあげたサービス要求管理のフローに沿ってサブプロセスに分類し各活動を説明する (2) 申請の起票所定の申請フォームがあればそれを利用し申請を起票するメニューにおいて価格が明らかでない場合は見積を取得する価格などの条件により承認が必要であれば所定の承認者に承認を求める承認が不要であれば要求受付に進む (3) 財務上の承認有料のサービス要求の場合は所属組織の上司などの承認者が費用面の承認 / 否認を行う (4) その他の承認目的の正当性や権限上の制約コンプライアンス上のチェックなどその他の承認が必要な場合に担当の責任者が承認を行う 2) 要求受付サービスデスクなどインシデント管理の初期プロセスとして実施される活動群である下記はインシデントをサービス要求 (SR) と置き換えて記載している (1) サービス要求の識別 SR インシデント管理の活動インシデントの識別に相当する承認状況など必要な申請手続きが行われていることを確認し受け付ける (2) サービス要求の記録インシデント管理の活動インシデントの記録に相当する (3) サービス要求のカテゴリ化インシデント管理の活動インシデントのカテゴリ化に相当するインシデントと同様に受付けられたサービス要求がここで分類され要求実現の対象となる 1) 要求申請ビジネス部門など IT サービスの利用側で実施される活動群である申請の起票以外は主体などの明示がないものの ITIL V3 の要求実現の記載でも触れられている (1) メニューの選択サービスの利用者がサービス要求のメニューから自身の要求しようとするサービスを選択する 3) 要求実現要求受付を経たサービス要求は必要な対応作業を各担当チームに割当てられ実施されるサービス要求のメニューによりその対応作業が異なるが複数の担当チームに割当てられる一連の対応作業の総体として要求が実現される (1) 対応作業依頼の受付サービス要求の受付もしくは先行する対応作 7

5 業が完了すると開始すべき対応作業について担当チームもしくは担当者に依頼が行われこれを受け付け担当者に割当てる (2) 対応作業の実施担当者が対応作業を実施する (3) 次の対応作業への引渡対応作業が完了した際次の対応作業があれば次の担当チームにサービス要求を引き渡す (4) サービス要求のクローズサービスデスクにて要求実現の全ての対応作業が完了したことを確認しサービス要求をクローズするこの活動は要求受付の最終活動と位置付けることもできる III. サービス要求管理の自動化またサービス要求管理の自動化により管理プロセスの KPI 計測が可能乃至は容易になるメトリックス収集の例を合わせてまとめる表 III-1 にあるように全般に画面入力支援や自動通知などのワークフロー管理機能の恩恵を受けることになる特に要求受付の活動は要求申請の段階をコントロールすることでサービス要求の識別分類や申請内容のチェックなどの自動化が実現し非常にシンプルに集約され画面で言えば1 画面の操作へと効率化できることが期待される尚メトリックスの取得については全般にサービス要求や対応作業の各レコード自体とそれらの起票更新時のタイムスタンプの記録 / レポート機能が前提となる II.2 に述べたサービス要求管理の活動は近年のツール普及によりかなりの部分が自動化の対象となりうる本章では SRM システムの構築に際し期待される自動化要件サービス要求管理プロセス上の各活動への効果をまとめる () / / / III.1 サービス要求管理の自動化要件とメトリックス SRM の自動化システムが構築されシステム上でサービス要求管理を運営する場合活動のニュアンスは II-2 の記載と違ったものになる表 III-1 に一般的に期待される自動化の要件をまとめておく基本的にワークフロー管理製品の利用により実現可能なものであるが導入される ITSM ツールとの統合を考慮することでシステム面でも SPOC( 単一窓口 ) が実現される / () / 8 / / () 表 III-1 サービス要求管理活動の主な自動化要件

6 IV. 要求実現における対応作業の管理とビジネスサービス要求上記で説明したサービス要求管理プロセスはサービス要求が個々に独立した流れで実現される場合の流れを示している本章では異なるサービス要求の実現が連携するケースに発展させて考えてみようワークフロー管理製品の IT サービスへの利用や SRM ツールの市販化は IT に対するサービス要求だけでなくビジネス上のいわゆ A A る業務サービスのサービス要求の管理を自動化する基盤を提供し IT とビジネスのサービス協調を支援する B 状況を迎えている B IV.1 要求実現における個々の対応作業の管理サービス要求の要求実現において一連の対応作業は通常サービス要求のメニュー毎に紐づけられた手続きとして定型化が求められる運用改善活動の中でサービス要求の必要対応時間の分析を試みることが良く行われるが要求実現の手続き全体で計測分析すると少なからぬ割合のサービス要求について個々の実績値にばらつきが大き過ぎて非定型な要素が多く定常的な改善が困難なものと分類されることになる手続きの中で発生するものがある例えば自社向けの PC 調達サービスで発生したサービス要求も顧客 ( 他社 ) 向けの PC 調達サービスで発生したサービス要求もその要求実現の手続きにおいては同一の対応作業として PC キッティング作業を同じ担当組織が実施することが考えられるその前後の作業は資産管理上の手続きや配送上の手続きなどサービス要求により別々の作業となっているケースである ( 図 IV-1) A-1 A-2 C B-1 B-2 図 IV-1 異なるサービス要求で共有される対応作業このようにサービス要求の単位で管理している場合は別々のサービス要求に埋没してしまうような個々の対応作業であるが管理単位を対応作業にまでブレイクダウンすることで異なるサービス要求に共通で発生する作業 ( 上例の PC キッティング作業 ) についてもパフォーマンス管理や改善策をうつことが可能になるのである勿論対応作業を担当するチーム別の視点で分析把握することもできる実はこのような手続きは手続きを構成する個々の対応作業の単位に踏み込むことで管理改善が可能になるケースが多い手続きが複数の対応作業で構成されている場合に特定の対応作業にばらつきを伴う待ち時間が発生すれば手続き全体の対応時間にそのまま影響が出てしまうからである他の対応作業を切り出して計測すれば十分に定常的な改善対象にできたりばらつきを伴う対応作業自体にも明確な対策を打てることがある尚待ち時間が発生する対応作業の例としては次節で述べるような異なるサービス要求間で共有される対応作業を含んでいる場合が少なくない IV.2 異なるサービス要求の実現手続きの連携要求実現の手続きに用いられる個々の対応作業に視点を移してみると対応作業自体は必ずしも一つのサービス要求手続きだけではなく複数のサービス要求 9 IV.3 ビジネスサービス要求への拡大とサービス要求の包含関係 ITIL におけるサービス要求は IT 部門や IT サービスプロバイダに対するリクエストを対象にしているが従来ビジネスを支える業務サービスにも同様にサービス要求は存在しているし ITO(IT アウトソーサ ) が BPO( ビジネスプロセスアウトソーサ ) を兼ねることも少なくない ITIL プロセスで言えば ITSCM が BCM を下支えするのも近しい包含関係を示している例えば新入社員の配属先オフィス情報連絡先まで含めた人事情報をインプットし社員証など総務関連の準備を依頼できる業務上のサービス要求 ( ビジネスサービス要求 A) があるとする一方で新入社員や派遣社員に関わらず作業 PC 一式を調達する IT 上のサービス要求 (IT サービス要求 B) がある

上例のケースではビジネスサービス要求 AとITサービス要求 B は別々のサービス要求であるサービス要求管理システムの範囲を拡大しビジネスサービス要求 A のようなサービス要求を同一の SRM システム上のメニューに加えた場合を考えてみよう新入社員を迎え入れる上司つまり SRM システムへの申請者にとっては二つのサービスは同じ時期に必要となり

7 上例のケースではビジネスサービス要求 AとITサービス要求 B は別々のサービス要求であるサービス要求管理システムの範囲を拡大しビジネスサービス要求 A のようなサービス要求を同一の SRM システム上のメニューに加えた場合を考えてみよう新入社員を迎え入れる上司つまり SRM システムへの申請者にとっては二つのサービスは同じ時期に必要となりまた共通の情報を都度入力しなければならないため同一の申請で済ませたいという要望が強まることは間違いないその対応としてビジネスサービス要求 AにITサービス要求 Bを含めたビジネスサービス要求 C というサービス要求がメニューに追加される ( 図 IV-2) もしくはビジネスサービス要求 A と置き換えられることになる V. まとめ本稿ではインシデント管理の一環で扱われがちなサービス要求についてインシデントとの違いを見直し要求の申請から始まり要求実現を含んだサービス要求の管理プロセスの活動をまとめたまたワークフロー管理製品や ITSM ツールを活用したシステム化基盤の普及を鑑みサービス要求管理の自動化における主な要件を抽出した今後 IT サービス要求に留まらずビジネスサービス要求を含めて一元化していくことによりサービス利用者の利便性が向上する一方で要求実現のマネジメントにおいては対応作業の単位での管理の必要性が高まってくるものと考えられる A A A-1 A-2 A-n ITB B B-1 B-2 B-n C C A-1 A-2 A-n B-1 B-2 B-n B ITB 図 IV-2 ビジネスサービス要求による IT サービス要求の包含このようにサービス要求のメニューが業務サービスにまで範囲を広げサービス要求の間に包含関係が生まれることで IV.1 にあげた個々の対応作業はますます多様なサービス要求に埋没していくことになるこのため要求実現のパフォーマンス改善のためには対応作業単位の管理がより必要になってくるものと考えられる 10 小澤一友株式会社シグマクシス / マネージャ ITIL V2 Manager/V3 Expert Certificate PMP ISO/ IEC Consultant Certificate 1992 年自然言語処理への関心から IT 企業に入社システム開発 / 保守特に広域監視システムの研究構築などシステム運用管理関連の経験を経て 2004 年 4 月 ITIL マネージャ認定を取得組織的な ITIL 活用推進品質改善活動に取組む以降 IT 企業数社にて IT 運用改善 IT サービスマネジメント導入コンサルティング IT アウトソーサ創業に際した品質マネジメントシステムの構築などを経験

要求仕様管理テンプレート仕様書

要求仕様管理テンプレート仕様書目次 1. テンプレート利用の前提... 2 1.1 対象... 2 1.2 役割... 2 1.3 プロセス... 2 1.4 ステータス... 3 2. テンプレートの項目... 4 2.1 入力項目... 4 2.2 入力方法および属性... 5 2.3 他の属性... 6 3. トラッキングユニットの設定... 7 3.1 メール送信一覧... 7 3.1.1 起票... 7 3.1.2 作成中...