サービス・ストラテジー の変更点
Top / サービス・ストラテジー
- 追加された行はこの色です。
- 削除された行はこの色です。
- サービス・ストラテジー へ行く。
- サービス・ストラテジー の差分を削除
[[ITIL]]の主たる要素の一つで、version 3においてITサービスの戦略や計画のベースとなる最重要トピック。 これなくして、その他のプロセス（サービス・デザイン、サービス・トランジション、サービス・オペレーション、継続的サービス改善）は立ち行かない。 ---- #contents ---- * 概要 [#n95f137e] [[ITIL]]の項でも触れたが、そもそもITとはビジネスを遂行するために不可欠な存在であるというコンセプトがあり、ITを利用してビジネスを行うためにはビジネスの目的や内容を把握しなければならず、その上でニーズを満たすための戦略を立てなければならない。 そのための必要な取り決めとして、提供すべきサービスやそれぞれの重要度・リソース・キャパ・予算などがあり、これらを総合的に勘案することが求められる。 なお、包含している範囲が広すぎて捉えどころがない或いは具体性がないというコメントもあるが、そもそも[[ITIL]]はマニュアルでなくガイドラインであるため、丁寧でない・ピンとこないといって投げ出さず、しっかりと読み解くことが肝要と考える。 主たる構成として下記の要素がある。 ** サービス・ストラテジ策定 [#ad976b32] 当然ながらサービスは現場のスタッフが提供していくわけだが、その提供するサービスの種類や質と濃淡などは各担当で決められるものではないし、実情を誰よりも知っているのが現場であることは間違いないが、どうしても主観に偏ってしまう面もある。かといって、外部からの意見だけに耳を傾けることが良い結果につながるわけでもない。 現場から状況を抽出し、他の部門からのニーズも吸い上げたうえで、スコープを定め、その達成に必要な予算を確保することは、マネジメント層が執り行わなければならない。 戦略を定めるにあたっては、 Perspective（観点）・Position（ポジション）・Plan （計画）・Pattern（パターン）という4つのPが肝要だとされ、これらと下記の要素を鑑みてまとめるべきだとされている。 *** 対象の決定 [#a15eaa68] どこに投資すれば、顧客やビジネスパートナーへの付加価値および業務効率化に対してより貢献できるか？を軸足として、対象となる「領域」を定める。 具体例としては、対象の組織（営業部や経理部など）、地域や営業所（支社や支店）、顧客、製品、事業、業務プロセスなど。 これらの切り口は、何を用いるのが正しいということでもないが、あくまでビジネスを軸足に決めること。「何に、何故、どういったことをなすべきか」が大事であって、「こういったことに対し、こういったことができる」というアプローチは一旦忘れてほしい。 *** サービスの決定 [#lea8ca69] 次は、基幹システムや携帯端末など、具体的にどういったサービスを提供するか？について。 漠然と「自社にとって、どういったITサービスを導入すべきか」と考えても、イマイチ浮かばないし根拠も薄いものとなるが、対象のビジネスをイメージできれば、そこそこリアルになってくるかと思う。 どんどん肉付けしていき、後述のサービス・ポートフォリオ管理に落とし込む。 *** リソースの確保 [#u082f4a4] これらで定めたターゲットにサービスを提供するための前提、つまりツールの整備や運用プロセス、アウトソーシングを含めたリソース管理なども考えなければならない。 ここの根拠が薄いと、せっかく定めたサービスも絵に描いた餅になってしまったり、中長期的な供給が難しくなってしまう。 ** サービス・ポートフォリオ管理 [#m3af42b3] サービス・ポートフォリオとは、IT部門や外部ベンダなどのITサービス提供者が取り扱うすべてのITサービスとそれに関する情報を意味し、それらを管理するプロセスとなる。 -[[サービス・カタログ]] 提供されるサービスの一覧で、対象、内容、料金などを含む。 -サービス・パイプライン 検討中または開発中であるサービス。 -廃止されるサービス 何らかの理由により、稼働中の環境から停止または廃止されるサービス。 ** 財務管理 [#v9bbce18] サービスを供給するために必要とされる資金を確保するプロセス。 コストパフォーマンスに優れるサービスをユーザに提供するため、トータルコストを測定し、[[ROI]]や[[ビジネスケース]]などの手法で分析する。 分析して「はい、そうですか」ではなく、投資と釣り合わないものは中止・改善しなければ意味をなさないが、そのための数値目標などの判定基準を定めるのは中々難しい。 対象や内容ごとの合理的基準を定めることに悩むくらいなら、まずは監視と評価を行うことを1st stepとしては如何だろうか。 実コストの分類や把握を目的とする会計業務、予算とのvarianceを監視し調整する予算業務、供給したサービスの対価を請求したり配賦する課金業務に分かれる。 なお、コストオーバーを許容する意図はないが、コストオーバーという事実だけに執着するのではなく、見積もりの甘さ((実績コストは適正で、単に見積もりが甘かっただけじゃないのか？など))や、超過してなお投資対効果があるか否かが重要と考える。 ** 需要管理 [#c8552033] ユーザのニーズと現在のキャパとを勘案し、サービスの供給を調整するプロセス。 利用者の[[事業活動パターン]]の分析と記録を行い、[[ユーザ・プロファイル]]との突合も行う。 * 補足 [#z077ab2e] [[BMC Software社のWebサイトで公開している記事>http://www.bmc.com/ja-JP/news/itil-column/ServiceDesign-Summary1.html]]があまりにも秀逸なので、さわりだけ引用させて頂く。 # あなたが「レストランを経営したい」と考えたとしましょう。 # 果たして「レストランを経営したい」と思った情熱ややる気だけで、 # 店を開店してうまくいくでしょうか。 # レストランを経営するにあたっては「どんなレストランにしたいのか」 # 「お客様の年代層や性別は」などといったコンセプトのようなものや、 # 「どのような料理をどのように作り、どのように提供するのか」といった # 具体的な内容を最初に考えるでしょう。 # また、コンセプトに合わせた店づくり、備品の調達や配置、店員の教育などについても考えなければなりません # また、コンセプトに合わせた店づくり、備品の調達や配置、 # 店員の教育などについても考えなければなりません こういった例でサービス・ストラテジーを解説し、更に、 # 例えば、レストランを「和食で高級志向のお店」とするのか、 # 「リーズナブルな中華料理の店」とするのかによっても、 # お客様に提供するサービスの定義が変わるでしょう。 # サービスの定義が変われば、お店の雰囲気をどうするか、料理の質や価格はどうするか、 # 食材の調達はどうするか、食器のデザインや枚数はどうするか、 # クレーム対応はどうするか、といったことがすべて変わります。 という説明で、[[サービス・デザイン]]に触れている。 システム屋が他のシステム屋に感心してばかりもいられないのだが、[[ITIL]]に興味を持たれた方は、是非コラムに目を通してみては如何か。 ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_iphone_book_itil) ~ ~ ---- #pcomment(reply)
