ITIL 2011 Edition Case Study 【Continuous Study】

1. ITIL - SOA, PPO, RCV, OSA AND MALC Yuko Soma 1 Case Study

2. 参考資料のご紹介最後までご清聴いただき、誠に、ありがとうございました。本プレゼンテーションの内容には、以下の資料を、参考にしてカスタマイズした部分が含まれております。第一次資料株式会社アーク著、『すご訳！コア書籍シリーズ』、東京、株式会社アーク、2013年株式会社アーク著、『ITIL鳥瞰図 (2011年版)』、東京、株式会社アーク、2013年株式会社アーク著、『ITILシナリオとケース・スタディ』、東京、株式会社アーク、2013年 EXIN著、『ITILエキスパート模擬試験』、東京、EXINジャパン第二次資料 Pyzdek, Thomas, and Keller, Paul, The Six Sigma Handbook, Fourth Edition, McGraw-Hill Professional, UK; 2014 Stark, Ed, Lean Six Sigma QuickStart Guide, ClydeBank Business Stephen R. Covey, THE 7 HABITS of Highly Effective People, Brilliance Audio, Inc. Michigan; 2012 PMI著、『プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第5版』、Project Management Education、2014年笹森俊裕・満川一彦著、『ITサービスマネジメント教科書 ITILファンデーションシラバス2011』、東京、翔泳社、2013年特定非営利活動法人itSMF Japan著、『ITサービスマネジメント事例に学ぶ実践の秘訣』、東京、翔泳社、2013年打川和男著、『図解入門ビジネス ISO20000 2011の基本と仕組みがよ〜くわかる本』、東京、秀和システム、2011年官乃厚著、『ITILの基礎 ITIL ファンデーション（シラバス2011試験対応）、東京、株式会社マイナビ、2014年野村総合研究所システムコンサルティング事業部著、『ITIL入門 ITサービスマネジメントの仕組みと活用』、東京、株式会社ソーテック、2012年 2

3. コミュニケーション基盤を統合するにはケーススタディ MALC 1の要約： ① 10の事業ユニットがそれぞれ独自の会議室予約などのシステムを使用しているので、たまに他の事業ユニットのシステムを借りることがあるなど、”効率の問題”や”セキュリティの問題”が多数ある。 ② そこで、10事業ユニットの社内グループウェアをひとつに統合し、コミュニケーション基盤を統合することにより、リスク軽減、コスト軽減、運用管理の負荷低減、生産性の向上を目指すことにし、全ユーザにアンケートを実施した。要望：千差万別な全ユーザからの要望アンケート結果を、どのようにシステムに取り入れたらよいか、ITILに基づいて、教えてほしい。解決へのステップ: ステップ1 使命と適用範囲の確認適用範囲 - 10のシンセン事業ユニット全て使命 - コミュニケーションツールの導入により、リスク軽減、コスト軽減、運用管理の負荷低減、生産性の向上を実現する。ステップ2 問題の分析優先度付けするために、MoSCoW分析を行なう。・必須要件：会議室予約が、6ステップ以内で、ダブルブッキングせずに可能となる。・将来検討要件： 3ステップ以内で、ヴィデオ通話が始められるようにし、固定電話サービスは廃止とする。 Yuko Soma – Case 1 - 1 ここが、プレゼンの始まりです。 3

4. コミュニケーション基盤を統合するにはステップ2 KPIを決める。 ① 有効なコミュニケーション計画を策定することを確実にする。（利害関係者の十分な賛同とコミットメント） ② 全会議室の予約方法の変更については、70%以上のユーザが認識していることを確実にする。 ② 導入費用(人件費増加分含む）については、2年以内に、導入前の費用と相殺できていることを確実にする。ステップ3 コミュニケーション・ツールを比較し、選択する。結論： ① ユーザのアンケート結果は、読まずに事業顧客に返却し、事業顧客側にまとめてもらう。 ② 事業関係マネージャに窓口を一本化し、事業顧客からの要望をヒアリングする。 ③ KPIの達成率をもとに、従来の問題が解決されたかを判断する。 Yuko Soma – Case 1 - 2 ここが、プレゼンの終わりです。比較要素（抜粋） Cybozu + Becky! sametime + Domino Lync + Exchange + Sharepoint Must 必須要件 100点 0点 100点 Should 推奨要件 80点 80点 80点 Could 検討要件 90点 80点 90点 Would 将来検討要件 50点 0点 100点カスタマイズする必要性ごくわずか有有運用コスト（保守）普通安価高価（＊この図は、筆者が考案したものです。） 4

5. 異なる事業ユニットの変更による矛盾ケーススタディ MALC 2の要約： ① 利害関係のある10の事業ユニットからのリクエストに応じて、ITサービスを提供している。 ② 事業ユニットAの要求を実現すると、事業ユニットBの要求が実現しないなど、矛盾が生じることがあるが、顧客の窓口が異なるため気がつかない。 ③ 変更が設計に反映されて、運用段階でトラブルになってはじめて、システム担当者がその矛盾に気がつく。ご要望：変更管理の強化以外の良い方法で、異なる利害関係のある事業ユニット全てを満足させるITサービスにするにはどうすればよいか、ITILで解決してほしい。 Yuko Soma – Case 2 - 1 事業関係管理サービス・オペレーションサービス・トランジションサービス・ストラテジサービス・デザイン継続的サービス改善サービス提供の各活動の調整活動のプロセス事業ユニットAサービス・プロバイダ機会変更要求苦情賛辞 ITサービス財務管理サービス・カタログ管理キャパシティ管理変更管理 SLM 事業ユニットC 〜J 事業ユニットB ここが、プレゼンの始まりです。（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 5

6. 異なる事業ユニットの変更による矛盾事業関係管理 (BRM)と顧客が、どのようなインプットから、どのようなアウトプットをもたらすか。結論： ① 事業関係管理マネージャが、単一窓口となることにより、リクエストに対する変更の矛盾を調整することが可能となる。 ② 各事業ユニットとの顧客合意ポートフォリオ群を、事業関係管理マネージャが、集中管理することにより、変更後の矛盾、クレームを解消することになる。 ③ 事業関係管理を導入することにより、CAB(Change Advisory Board)への出席者は、最小限ですむようになり、事業顧客の負担も減る。 Yuko Soma – Case 2 - 2 ここが、プレゼンの終わりです。事業活動パターンビジネス・ケース顧客合意ポートフォリオサーボス・ポートフォリオ SLMによって更新されたSLA 更新されたサービス・モデル BRMと顧客 SCMによって更新されたサービス・カタログ・ MS Lyncサーバ導入・ MS Sharepointサーバ導入・ Sametime, Notes DB, Notesメール廃止インプットアウトプット顧客ポートフォリオアプリケーションポートフォリオプロジェクト・ポートフォリオ・ヴァーチャル・ファースト・オンプレミス・ファースト・リース・ファースト・マイクロソフト・ファースト・サービス時間は、ユニットごとに異なってよいが、9:00 – 17:00以外は、5%増しでチャージ。（＊この図は、筆者が考案したものです。） 6

7. 社員を今の待遇のまま、利益をあげるにはケーススタディ MALC 3の要約： ① 中国にある事業ユニットで、中国の経済発展に伴い、安価に、優秀な人を採用することが困難になってきた。 ② 社員たちは、企業の存続を脅かすような要求をつきつけ、勝手な行動をし、向上心もなくなり、顧客からのクレームが増加した。 ③ 退職者も多いが、待遇を上げると赤字になるので、新規採用者、既存社員の待遇は上げられない。要望：中国から撤退はせずに、社員を今の待遇のままのりきるには、ITILでは、どのように解決するのか教えてほしい。解決へのステップ: ステップ1 使命と適用範囲の確認適用範囲 - 深圳事業ユニットの深圳拠点の新規採用者と既存社員使命 - 転職率を低減させるとともに、士気を高めて事業への貢献度を向上させる。ステップ2 閉モニタ・コントロール・ループ・システムで、社員の動向を監視し、変更の調整をする。 Yuko Soma – Case 3 - 1 ここが、プレゼンの始まりです。活動アウトプットインプット基準コントロール比較モニタ・安価で優秀な人材が採用できていた時代の状態・顧客クレームが少ない状態・社員の士気が安定している状態・マネジメントからの指導・ビジネスプロセスの改善サービストランジション・士気、勤務継続ヒト、知恵事業利益サービスオペレーション（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 7

8. 社員を今の待遇のまま、利益をあげるにはステップ3 従業員満足度(ES)の向上につとめ、顧客満足度につなげる。ステップ4 顧客満足度(CS)が上がれば、事業価値が創出され、将来的には、社員の適切な報酬につながる。結論：適切なITガバナンスで、プロセス全体を監視、調整することにより、CS, ESを向上させ、事業価値をうみだす方針を打ち出すことに成功すれば、離職率の上昇、士気の低下の問題を解決できる。 Yuko Soma – Case 3 - 2 ここが、プレゼンの終わりです。 ITガバナンスの方針項目具体にどのように・・・ A) 明確なキャリアパス人事部長からのメッセージ B) トレーニング機会、能力の向上 OJT、社内勉強会などによるトレーニング機会の創出 C) 希望、やりがい、モチベーション上級マネジメントからのメッセージ D) 適切な報酬パフォーマンス・ゴールなど、個人の達成度により報酬を与える ITガバナンス従業員満足度(ES)顧客満足度(CS) 事業価値（＊この図は、筆者が考案したものです。）（＊この図は、筆者が考案したものです。） 8

9. デミングサイクルの種類についてケーススタディ MALC 4の要約： ① 組織的な統合をとらずに、自己判断に任せて経営してきたが、別の会社は、当番制を採用し、組織的統合がある。 ② 自社でも、近代的なマネジメントシステムを取り入れたいと考えている。要望： PDS、PDCA、PSDA、CAP-Doなど、色々なマネジメントサイクルがあるが、どれか例にとって、説明してほしい。解決へのステップ: ステップ1 使命を確認する。下図のように、継続的にマネジメントサイクルをまわして、上昇させることにより、事業とITを統合することを使命とする。 Yuko Soma – Case 4 - 1 ここが、プレゼンの始まりです。 Plan DoCheck Act 時間の経過成熟度レベル事業とIT の統合 Plan DoCheck Act Plan DoCheck Act （＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 9

10. デミングサイクルの種類についてステップ2 複数の解決案を比較し、推薦案の決定以下の3つを比較すると、この会社は、まだ、ITILを導入しようとしている段階なので、CAP-Doを推薦する。結論： ① どの形態が良いかは、その顧客のITILプロセスの成熟度、カルチャ、個別の課題にもよるが、この企業の場合は、CAP-Doを推奨する。 ② プロセス成熟度が上がったら、計画(P)を開始点とした、PDCAに変更し、コスト削減に重点をおくとよい。 Yuko Soma – Case 4 - 2 ここが、プレゼンの終わりです。名称概要欠点・利点 ① PDS (Plan, Do, See) マネージャは、Actをしないと考えられるので、CheckとActを合わせて、See （見届ける）とした。欠点：ワーカの場合にはActが必要なので、適応しないことがある。 ② PDCA (Plan, Do, Check, Act) ITILでの、一般的なデミングサイクル利点： Planに時間をかけるので、手戻りが少なくなり、費用対効果が高い。欠点： ITIL初心者だと、Planの部分に時間がかかりすぎて、実行に移すまでの時間が長くなりすぎる。 ③ CAP-Do (Check, Act, Plan, Do) Checkから始まるデミングサイクル利点： ITIL初心者には、Checkから始めて、改善するほうが、結果が早くでるので、士気が上がる。欠点： Planを始めにしないと、手戻りが多く、コストがかかる。（＊この図は、筆者が考案したものです。） 10

11. 事業ユニットの立上げ方法についてケーススタディ MALC 5の要約： ① 新しく選任された社外取締役が、とりわけ海運事業である、新船事業ユニットに関心をしめし、どのようにビジネスを開始したかなどについて、質問をしてきた。 ② 文書化した当時の資料がないため、取締役の質問に答えられない。要望：新船事業ユニットの立上げ方法を推測し、ITILを用いて、代わりに答えてほしい。回答：以下のように、歴史的に、新船事業ユニットは成長していったと推測される。 Yuko Soma – Case 5 - 1 ここが、プレゼンの始まりです。創業当時 140年前ネットワークによるサービス・指揮命令系統が無かったので、スピードと創造性はあるが、ワーカーの個人プレーが目立っていた。 90年前指示によるサービス・リーダーを設置することにより、ITサービスマネジメントの基礎ができたが、ワーカーの自主性の喪失が課題となった。 10年前委任によるサービス・ 36管理プロセス導入により、ワーカーは自主的に仕事をするようになったが、業務が分散され、上級マネージャが管理しきれていないというコントロールの課題が発生した。 5年前調整によるサービス・ CIO、プロセス・オーナ、プロセス・マネージャの階層型のマネジメント導入によりコントロールの課題が解決したが、官僚主義的になってしまった。現在恊働によるサービス・機能別マネージャとプロジェクト・マネージャの双方に管理されつつも、各自が、柔軟性をもって自由に繋がり、適時、マネージャに報告するという、マトリックス構造組織になった。（＊この図は、筆者が考案したものです。） 11

12. 事業ユニットの立上げ方法についてまとめ：組織の変更には、トップマネジメントを巻き込み、全メンバーの理解とコミットメントを得る必要がある。望ましい状態で固定することに成功してから、ひとつ上の段階へ進むとよい。 Yuko Soma – Case 5 - 2 ここが、プレゼンの終わりです。恊働によるサービス調整によるサービス指示によるサービス委任によるサービスネットワークによるサービスリーダーシップの課題自主性の課題コントロールの課題官僚主義の課題管理の激変の段階組織の発展段階組織を現状の状態から解放する望ましいタイプの変更を行なう組織を新たな望ましい状態で固定する Step 1 Step 2 Step 3 新船ユニット創業当時新船ユニットの現在（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。）（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 12

13. 情報システム部刷新プロジェクトケーススタディ MALC 6の要約： ① 情報処理量が増大したため、以前、ITサービスの企業を吸収合併したが、その企業は、レガシーシステムを得意とし、慎重なため、変化に対応するスピードが遅い。 ② 今は、人員増員をした結果、元のメンバーと新規メンバーが入り混ざった状態になり、人事異動もしなかったため、事業ユニットごとに、ITの文化が微妙に異なってきている。 ③ 事業ユニットごとに、インフラストラクチャ、アプリケーション、契約ベンダーが異なるため、今までユニットごとにセットだったアプリケーション管理と技術管理を分離させ、ユニットを超えて、それぞれの高度な技術を集約させたいと考えている。要望：以下の全てを、ITILで成功をさせる方法を教えてほしい。 a. マネジメント体制 b. マネジメント間のコミュニケーション c. メンバの不満を和らげる方策 d. 技術者が所有するスキルの統合の方策 e. アプリケーション間のインターフェイスのあり方 a.b,cの解決策：マネジメント方法の改善により、メンバの感情のサイクルをスピーディーにする。 Yuko Soma – Case 6 - 1 ここが、プレゼンの始まりです。最適なパフォーマンス受け入れ自己批判外部への非難回避動揺時間パフォーマンス図：変更に伴う感情のサイクル動揺回避最適なパフォーマンス時間短縮受け入れ（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 13

14. 情報システム部刷新プロジェクト d,eの解決策： d まずは、サービスごとにカテゴリ分けし、全事業ユニットに同じアプリケーション・サービスを提供することにより、チーム数は、10ユニット x 4サービス = 40チーム → 8チームに技術を集約する。 e 関連するアプリケーション・サービスをまとめ（クラウドかオンプレミスかなど）、サプライヤを集約する。 Yuko Soma – Case 6 - 2 ここが、プレゼンの始まりです。ここが、プレゼンの終わりです。事業ユニット1 事業ユニット2 事業ユニット3 事業ユニット10 イントラネット・サービス技術管理チームA アプリケーション管理チームA ITSMツールサービス技術管理チームK アプリケーション管理チームK 顧客管理DB サービス技術管理チームB アプリケーション管理チームB 会計システム・サービス技術管理チーム4 アプリケーション管理チーム4 クラウドオンプレミス（＊この図は、筆者が考案したものです。） 14

15. ITサービス停止対策チームケーススタディ MALC 7の要約： ① 先日、「Disk Full」メッセージを出して、アプリケーションAとOSが、同時に停止し、結果、レガシーシステムのサービス停止が発生した。 ② その前に、アプリケーションAに対する小さな機能追加は、確認テストはされず、本番に移行されていた。 ③ また、HDDの必要空きスペースの見直しがなされていなかった。 ④ このサービス停止により、DBが壊れている可能性があるため、バックアップテープよりリロードしようとしたが、2 年前に、アプリケーションCに大きな機能追加があったにもかかわらず、バックアップに関する修正がぬけおちていたため、失敗した。 ⑤ これらの原因は、5年前、誤って各種マニュアルを削除してしまい、それ以降、各自、自己判断で対応していたことにあった。要望： ITサービス停止対策チームを発足させたが、このレガシーシステムのトラブル再発防止の効果をあげるには、ITIL を用いて、どうしたら解決できるか教えてほしい。解決へのステップ: ステップ1 リスクアセスメントの実施 ① ブレインストーミングによるリスクの識別 (適切なリスク定義） ② リスクのインパクト、確率の定量化 (100%の場合は課題となり、リスクから除外。その他の場合は、リスクの格付けをする） ③ リスクの管理（文書化、レビュー、モニタリング、処置、確認）ステップ2 ドキュメントの再作成サービス・オペレーション段階で使用する、「各種マニュアル」を復活させるため、サービスストラテジからやり直し、ビジネス・ケース、サービスモデル、サービスデザインパッケージの作成を実施する。 Yuko Soma – Case 7 - 1 ここが、プレゼンの始まりです。 15

16. ITサービス停止対策チームステップ3 ITサービス停止対策プロジェクトの実施サービスデスク、IT運用管理、アプリケーション管理、技術管理が恊働で、ITサービス停止対策プロジェクトを成功させる。結論：下図のドキュメントが欠けていると、サービスの可用性が失われ、変更管理がうまく行なわれない。 Yuko Soma – Case 7 - 2 ここが、プレゼンの終わりです。サービストランジションサービスデザインサービスオペレーション技術管理サービスストラテジアプリケーション管理サービスデスク ITサービス停止対策プロジェクトチームサービス・モデルビジネス・ケースサービス・デザイン・パッケージ各種マニュアルサービスデスク・ IT運用管理（＊この図は、筆者が考案したものです。） 16

17. アウトソーシングとインソーシングケーススタディ MALC 8の要約： ① 全てのシステムを自社開発し、運用してきたが、変更要求の増加、ハードウェア、ソフトウェアの種類の多さと進歩の早さから、対応の遅れもでてきて、コストも増加している。 ② 情報システム刷新プロジェクトは、これらを改善し、アウトソーシングを視野入れることを考えだした。 ③ これを機に、情報子会社を設立して、社長になろうと思う。情報子会社が設立できなくても、コスト削減の成果が認められればが、CIOになれるかもしれない。要望：アウトソーシングとインソーシングのメリット、デメリットを明らかにして、バランスよく取り入れて、周囲を納得させる方法をITILを例に教えてほしい。解決へのステップ: ステップ1 サービス提供戦略を考える。 Yuko Soma – Case 8 - 1 ここが、プレゼンの始まりです。ソーシング構造メリットデメリットインソーシング ① 直接的なコントロール ② 選択の自由 ③ 熟知した方針、または、プロセス ④ 企業固有のナレッジ ① 規模の制限 ② 外部から容易に入手可能なサービスに対するコストアウトソーシング ① 規模の経済 ② 専門知識の購入 ③ 一時的なニーズに対する支援 ① 比較的直接的でないコントロール ② サプライヤの破綻リスク ③ ガバナンスと妥当性確認の増大マルチソーシング ① 市場投入までの期間 ② 専門知識の活用 ① プロジェクトの複雑化 ② 知的財産権、および著作権の保護の課題 ③ 企業間カルチャの衝突の可能性（＊この図は、ITILコア書籍をもとに、カスタマイズしたものです。） 17

18. アウトソーシングとインソーシングステップ2 ソーシング戦略を考えるスッテプ3 変更管理の課題、リスクに対するソーシング・ソリューションを考える結論： ① サービス提供戦略と、ソーシング戦略を組み合わせて、計画をたてる。 ② 計画は、ビジネス・ケースを作成して、具体的なROIを出して、定量化する。 ③ 最終的には、企業のカルチャ、サービス・ポートフォリオの複雑さ、能力、スキルセット、力量などを考慮して、決定する。 Yuko Soma – Case 8 - 2 ここが、プレゼンの終わりです。ソーシング構造例ローカル・ソーシングベンダー契約をし、オフィスに常駐してもらうマルチショア・ソーシング APAC, EMEA, North Americaに、サービスデスクを配置ニアショア・ソーシング大連市にカスタマー・センターをつくるオフショア・ソーシングデンマークに開発センターと製造工場をつくる課題ソーシング・ソリューション ① RFCが増加しているインソーシングのままのほうが、変更管理がしやすい。 ② ハード・ソフトの種類が多すぎるローカル・アウトソーシングで、アセット管理してもらう ③ ハード・ソフトの進歩が早すぎるオフショア開発アウトソーシングで専門知識の購入（＊この図は、筆者が考案したものです。）（＊この図は、筆者が考案したものです。） 18

19. 議論をしたにもかかわらず、ビジネスが失敗した原因ケーススタディ MALC 9の要約： ① 辞書編纂作業請負では、収益が上がらないため、「新ビジネス検討プロジェクト」を立ち上げ、新規ビジネスを考えている。 ② ブレーンストーミングの結果、「日本の将来のために役立つことを新規ビジネスにする、我々は出版業が得意である、若者は、漫画などの軽いものを好む、日本の将来は若者の読書の質にかかっている」という状況認識だとまとめられ、取締役会の承認を得た。 ③ 新ビジネスの検討の議論により、あるシリーズの出版を決め、リスクの吟味も行なった。 ⑤ ところが、シリーズが全く売れず、緊急で出版した、続きのシリーズも全く売れず、在庫となった。要望：議論を重ね、リスクにも注意したのに、失敗に終わったのはどうしてか、ITILに基づいて教えて欲しい。回答: ① 緊急出版をする前に、ビジネス・ケースを作成し、取締役会で、投資の規模について承認されていたのか？ Yuko Soma – Case 9 - 1 ここが、プレゼンの始まりです。創造的・革新的成長自由裁量非自由裁量中核事業変革 (TTB) 事業拡大 (GTB) 事業運営 (RTB) 高低リスク新シリーズの出版緊急出版一連のプロジェクトなのに、ギャップが発生 (組織が行きたい場所) (組織がいる場所) （＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 19

20. 議論をしたにもかかわらず、ビジネスが失敗した原因 ② 緊急出版を行なう前に、RACIマトリクス通りに、変更許可が実施されていたのか？結論： ① 投資リスクの高い案件については、取締役会の承認が必須である。 ② 緊急出版の是非について、取締役会役員に、RFCの提出→相談→報告されていなかった可能性が高い。 Yuko Soma – Case 9 - 2 ここが、プレゼンの終わりです。プロセスの役割顧客変更の要求元変更の実行者変更マネージャ CAB ECAB 担当役員取締役会リスクレベルを決定する n/a C AR リスクレベル5 – 標準的な変更現場の許可 n/a C RI A リスクレベル4 – 低リスクの変更変更マネージャの許可 n/a C RI A リスクレベル3 – 現場またはサービスのグループにのみ影響がある n/a C AR CI リスクレベル2 - 複数のサービスまたは事業部に影響がある n/a C AR C CI リスクレベル1 – 高コスト、高リスクの変更（アセスメントのため、RFC を取締役会へ） n/a C AR CI （＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 20

21. 技術的な問題か、人為的な問題かの切り分けケーススタディ MALC 10の要約： ① 取り扱う生鮮食品の廃棄率が高くなっている。 ② 流通経路で、気がついた時点で、部門や委託先が、廃棄することになっており、良品の中に紛れるリスクと運用コストが余計にかかるリスクを低減している。 ③ 生鮮食品の包装を変更して、廃棄率が減少するはずであったのに、なぜか増えており、流通経路で足りなくなり、とうとう、納品できないという事故が起きた。要望：技術的な問題だったのか、人為的に不正が行なわれていたのか、ITILを用いて、切り分けて、解決策を提示してほしい。解決へのステップ: ステップ1 矛盾が生じているのはなぜか、以下の用法で、技術的ミス（廃棄率測定ミス）を疑ってみる。 Yuko Soma – Case 10 - 1 ここが、プレゼンの始まりです。 ① このデータをどのように収集したか？ 50人のリモート在庫担当スタッフが入力 ○ ② 誰がデータを収集したのか？在庫管理担当の短期派遣スタッフ、John △ ③ データを収集するために、使用したツールは？ Salesforce.com ○ ④ 誰がデータを処理したのか？在庫管理マネージャの新人、Sara △ ⑤ どのようにデータを処理したのか？ただ、所定のボタンをクリックしただけ。 △ ⑥ 正しくない情報につながった要因は何? 要分析 △ （＊この図は、筆者が考案したものです。） 21

22. 技術的な問題か、人為的な問題かの切り分けステップ2 矛盾が生じているのはなぜか、以下の用法で、人為的不正を疑ってみる。ステップ3 矛盾が生じているのはなぜか、ギャップ分析にて、ITサービスマネジメントのプロセスの要因を疑ってみる。結論：技術的ミス、人為的ミス、プロセスのミスの3つの観点から、上記リスト①〜⑭に基づいて洗い出し、問題があった項目については、事実の問い合わせ先がない項目についてブレインストーミングを行い、つきつめる。 Yuko Soma – Case 10 - 2 ここが、プレゼンの終わりです。 ⑦ 不正を働きそうな社員はいないか？いない ○ ⑧ 不正を働きそうな外部委託の社員はいないか？不明なので、要調査。 △ ⑨ 不正が生じる可能性のある段階/場所はないか？トラックの中 △ ⑩ ミスが生じる可能性のある段階/場所はないか？梱包時 △ ⑪ 組織構造と要員の能力はどうか？教育チームに問い合わせ中。 △ ⑫ 事業の方向性はどうか？ CIOに確認中。 △ ⑬ ビジネス・プロセスはどうか？ここに原因がありそうだ。 × ⑭ 情報技術はどうか？問題ないと思う。 ○ （＊この図は、筆者が考案したものです。）（＊この図は、筆者が考案したものです。） 22

23. 戦略的計画立案ケーススタディ MALC 12の要約： ① 中韓の同業他社の追い上げが激しく、主力製品の低価格競争に巻き込まれている。 ② 新製品の開発スピードが他社と比較して遅くなっているようだが、何が問題なのか、定量化できていない。 ③ アイディアはあるが、改善コストがかかるのと、数多くのファクターが絡むため、改善の決断もできていない。要望：自社開発、自社生産、自社販売網でビジネスを行なってきたが、これからもこれでいいのか、ITILに基づいて、解決策を提示してほしい。解決へのステップ：ステップ1 SWOT分析を行い、自社製造主義を変えないメリット、デメリットを知る。 Yuko Soma – Case 11 - 1 ここが、プレゼンの終わりです。強み： ① 独自の生産、販売ルートがある。 ② 新製品を開発する力がある。 ③ 10もの事業ユニットのノウハウが利用できる可能性がある。脅威： ① 中国、韓国の競合他社の追い上げが激しくなって来た。 ② 中韓の低価格競争に巻き込まれている。機会： ① 中国、韓国などの海外市場が大きい。 ② 円安で、中韓への輸出がしやすい。弱み： ① 新製品の開発スピードが十分とは言えなくなって来た。 ② 投資が数値化されていない。 ③ 10の事業ユニットのノウハウが利用しきれていない。（＊この図は、筆者が考案したものです。） 23

24. ステップ2 自社製造から、アウトソース製造に切り替えた場合のビジネス・ケースを作成し、投資利益率(ROI)を見る。結論： SWOT分析の後、製造をタイにアウトソースした場合のビジネス・ケースと、日本国内で自社製造のままの場合のビジネス・ケースを作成し、比較検討し、意思決定をする。 Yuko Soma – Case 11 - 2 ここが、プレゼンの終わりです。戦略的計画立案戦略的カテゴリ低コストで製造された、競争力のある製品の導入 A. 序章（事業目標の提示）自社製造主義から、タイでのアウトソース製造に切り替えて、より競争力のある製品を提供する。 B. 方法と想定事項（ビジネス・ケースの境界定義）対象：補聴器製造部門実施時期： 2015年6月〜組織的背景：価格競争が激しくなっている今、コストがかかるのに、今後も引き続き、自社開発、自社製造、自社販売網でビジネスをしていいのかが問われている。手始めに、製造だけでも、アウトソースできないかというアイディアが役員会で持ち上がった。 C. 事業へのインパクト(財務的、および財務以外の結果) ① アウトソース先とのナレッジ共有のための導入コスト 1000万円 ② アウトソース先への教育コスト 2000万円 ③ アウトソースにより、100人分の人件費を削減 2000万円 ④ アウトソースにより、製造コストの削減 1000万円結果：・財政面 - ROIは、3000万円/3000万円=1.0 ・非財政面 - より効果的なマーケティングに従事する能力。調達と保管のコスト削減につながる、より優れた在庫レベルの予想。アウトソース製造による顧客ロイヤルティの低下。 D. リスクと緊急事態（別の結果が発生する確率） ① カルチャの違いによる失敗リスク発生確率10% ② 自然災害による製造遅延リスク発生確率20% ③ 突然の退職、欠勤、デモのリスク発生確率5% E. 推奨事項（具体的措置）自社製造のままでいった場合のビジネスケース作成で、比較検討する。（＊この図は、筆者が考案したものです。） 24

25. リスク回避、軽減方法についてケーススタディ MALC 13の要約： ① コストセンターであった、情報システム部をプロフィットセンターにするため、独立した事業ユニットにしたい。 ② そして、外部サービスプロバイダ・ビジネスも始めたいと考えている。要望：採算についての責任を問われることは極力、回避、軽減したいが、どのようなリスクが考えられるか、また、回避策として何が考えられるか、ITILを用いて提案してほしい。解決へのステップ: ステップ1 リスク回避、軽減のために、外部環境を知る。 Yuko Soma – Case 13 - 1 ここが、プレゼンの始まりです。チェック項目問い答え業界と市場の分析特定の種類のサービスをアウトソーシングする傾向があるか？ホスティング・サービス。サービスデスク。オンサイト・サポート。ペイロール。ファシリティ。顧客顧客は誰か？どのような課題や機会に直面しているか？顧客の戦略は何か？ ITスタッフの固定費削減。ビジネスをITで成功させること。競合者競合者はどのように差別化を行なっているか？より費用対効果の高い方法を見つけているか？金融システムに特化している。短期派遣スタッフの活用をしている。業務のマニュアル化を推進している。法規制インパクトを与える法規や標準は何か？競合者も同じ制約に直面しているか？ ISO27001。ISO13485抜き打ち監査の開始。個人情報保護法。労働者派遣法改正法案。ホワイトカラーエグゼンプション法案。政治政治の変化によってどのようなインパクトを受けるか？強化するか、制限するか？ GDP1.6減により、消費税10%引き上げの延期。衆議院解散総選挙。法人税減税の見送り（＊この図は、筆者が考案したものです。） 25

26. リスク回避、軽減方法についてステップ2 リスク分析の方法を選択する。 ① リスクの管理(M_o_R: Management Of Risk) ② ISO31000 ③ ISO/IEC27001 ④ Risk IT 結論：リスクを特定し、分析し、評価するという3ステップがあるのが、ISO31000である。他にもさまざまなリスク分析方法があるので、ITILコア書籍を参照するとよい。 Yuko Soma – Case 13 - 2 ここが、プレゼンの終わりです。組織の状況の確定プロセスリスク特定リスク評価リスク分析リスク対応モニタリングおよびレビューコミュニケーションおよび協議リスクアセスメント（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 26

27. 品質と価格について市場調査するケーススタディ MALC 14の要約： ① ミネラル・ウォーターの販売において、中国への進出を計画している。 ② 中国では、高所得者層の増加により、ミネラル・ウォーターの需要が増しているし、日本のミネラルウォーターの品質は良い。 ③ これまで、日本から進出した同様の企業は失敗しているのは、品質は良いが、高価だからだと推測されているが、定かではないので、この原因調査のために、新規プロジェクトをたちあげた。要望：原因が価格ならば、引き下げてもよいと考えているが、それでも失敗した場合は、どうすればよいのか、ITILを用いて教えてほしい。解決へのステップ: ステップ1 中国現地にて、クロスビーのＴＱＭアプローチを使い、マーケティングを行なう。経営者にとって、「顧客の要求」がすべての中心である。 ①品質とは、顧客要求への適合性である (成果＝顧客の要求±欠陥) ②品質を生み出す仕組みとは、査定・評価ではなく予防である (事後ではなく事前が大切) 分からなければ、顧客の調査を実施する。個人ならば嗜好調査、企業ならば事業活動パターンの調査。顧客も分からなければ、テストマーケティングなどを行う（言っていることは建前、本音はやっていること） Yuko Soma – Case 14 - 1 ここが、プレゼンの始まりです。（＊この文章は、筆者が（株）アークの資料の文章を、引用、カスタマイズしたものです。） 27

28. 品質と価格について市場調査する（続き）作り手の目線から、買い手の目線へ・「プロダクトアウト」 … 作れば売れる時代の思想。良い物を作りさえすればよい。・「マーケットイン」 … 消費者の立場にならないと、作るべき物が分からない。・「マーケットアウト」 … 「マーケットイン」は、目線は消費者に向いているが、体はまだ生産者側に残っている。体ごと消費者と一体化し、そこから目線を生産者、工場に向けるべきである。ステップ2 サービスの値ごろ感で、ミネラルウォーターの価格設定を行なう。ステップ3 常に変化する市場を調査し、製品およびサービスを改善し続ける。結論： ① 価格が安ければ売れるということはない。「マーケットアウト」でサービスの値ごろ感を知れば、失敗するリスクは減る。 ② 失敗したとしても、改善し続けることで、中国市場に残り続けることができる。 Yuko Soma – Case 14 - 2 ここが、プレゼンの終わりです。純資産利益率顧客資産のパフォーマンス有用性保証パフォーマンスの平均値パフォーマンスのバラツキ製品およびサービス有用性 - 目的に適しているか・パフォーマンスがサポートされるか。・制約が排除されるか。保証 - 使用に適しているか・可用性は十分か・キャパシティは十分か。・継続性は十分か。・セキュリティは十分か価値の創出価値事業成果認識好み（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。）（＊この文章は、筆者が（株）アークの資料の文章を、引用、カスタマイズしたものです。） 28

29. なぜなぜ分析ケーススタディ MALC 15の要約： ① 自ユニット（日本）で、中国でのミネラルウォーターの販売を決定したが、中国現地での市場調査のノウハウがないため、中国での別ビジネスを開始している別ユニット（日本と中国）の協力を得ることにした。 ② 顧客からの注文は、別ユニット（日本と中国）が受け、発送・納品は、自ユニット（日本）で行なうITサービスシステムを新規開発した。 ③ ミネラルウォーターの在庫は、中国5箇所に置き、各倉庫で不足があったときは、融通しあうことになっており、日本から、欠品による機会損失に備えてバックアップ体制をとっている。 ④ 中国で別の会社による、偽ミネラルウォーターが摘発されたタイミングで、自社製品の発売日となったため、注文が殺到した。 ⑤ B to B用の狭い帯域のネットワークを使用したシステムに、営業が入力したトランザクションが大量発生し、ネットワーク・キャパシティ不足のため、システムがほとんど反応しなくなった。要望：結果的に、在庫データと在庫数に乖離が発生してしまったが、今後、このビジネスはどうなるのか、それをサポートするITシステムはどうしたらよいのか、ITILで解決してほしい。ステップ1 「なぜなぜ分析」で、問題の原因を知る Yuko Soma – Case 15 - 1 ここが、プレゼンの始まりです。現象システム上と倉庫の在庫数が合わないネットワークの帯域のキャパシティ不足によるレポジトリの不具合が発生した。どのくらいの需要があるのかが不明だった。需要管理、キャパシティ管理が未導入だった。その不具合のために連絡をとりあう方法がわからなかった。コミュニケーション計画がなかった。なぜ？なぜ？なぜ？なぜ？なぜ？（＊この図は、筆者が考案たものです。） 29

30. なぜなぜ分析 Yuko Soma – Case 15- 2 ここが、プレゼンの終わりです。種類（抜粋）目的（抜粋）頻度対象者内容状況/情報源変更に関するコミュニケーション日本と中国、双方のチームの環境において、変更を構築し、テストし、展開すること。変更の性質、および変更スケジュールに記載される時期によって決まる。 ① 変更マネージャ、変更管理者、変更調整車 ② 変更、またはリリース展開チーム ① 変更活動のスケジューリング ② 各チームに要求される変更と活動の詳細な説明。 ① RFC ② 変更コントロールのコミュニケーション（メール、電話会議、変更管理ツールを使用） ③ CABミーティング例外に関するコミュニケーション ① 例外を適切な人に通知すること。 ② 例外の重要性、重大度、およびインパクトを評価すること。 ③ 例外によって影響を受ける利害関者に、最新の情報を提供すること。例外が検知されると、コミュニケーションの頻度と内容は、例外のインパクト、緊急度、および重大度によって決定される。 ① インシデント管理のサポートスタッフ ② 問題管理のサポートスタッフ ③ 部門のマネージャ、またはチームリーダー ① インパクトのアセスメント ② 解決のコストの見積もりとその後の確認 ③ 実行するべき処置の決定 ① プロセス・レビュー ② プロセス、装置、チーム・パフォーマンスなどの傾向分析 ③ インシデント・レコード、問題レコード、および変更レコード、顧客満足度調査緊急事態に関するコミュニケーション ① インシデントのインパクト、及び重要度を迅速に調査する。 ② ITSCPに記載された災害、またはあらゆる緊急事態に・・・・（中略）例外が検知されると、コミュニケーションの頻度と内容は、例外のインパクト、緊急度、重大度、サービス復旧計画によって決定される。この状況を解決することが求められているITスタッフに対して責任を負うグループの上級マネージャ ① インパクトのアセスメント ② 解決のコストの見積もりとその後の確認 ③ 実行するべき処置の決定 ① 重大なインシデントのインシデント・レコード ② イベント ③ 危機ミーティングまたは緊急ミーティング結論： ① 需要管理、キャパシティ管理、コミュニケーション計画を導入することで、再発防止になる。 ② 今回起きた緊急事態に関する反省点を、継続的サービス改善(CSI)管理表に記載し、ターゲット日を決めて、改善にあたるとよい。ステップ2 コミュニケーション計画を策定する（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 30

31. 報告書作成方法ケーススタディ MALC 16の要約： ① 情報システム刷新プロジェクトは、全てのプロセスと機能をITIL準拠に移行完了した。 ② ところが、「Plan Doが終わっただけで、上級マネジメントの仕事であるSeeは終わっていない」と指摘を受けた。要望： Seeに関して、長い報告書はいらないので、一文字で結論を報告するよう、依頼されたが、ITILでは、どのように報告すべきといっているのか、教えてほしい。解決へのステップ: ステップ1 使命の確認をする情報を受け取る人が、戦略的、戦術的、および運用上の意思決定を行なえるように提示することを使命とする。ステップ2 目的と価値を明確にする。 Yuko Soma – Case 16 - 1 ここが、プレゼンの始まりです。 1 報告の対象者は誰か芦沢会長 2 報告書は何に利用されるか。 ITIL準拠のサービスになったかの確認に利用される 3 報告書の作成には、誰が責任を負うかプロジェクト・マネージャ 4 どのように作成するか上級マネジメント向けバランス・スコアカードの結果を元に作成する 5 どのくらいの頻度で作成するか本プロジェクト完了時に一度だけ。後は、要求による。 6 どのような情報を生み出し、共有化し、交換するか芹沢会長には、プリントアウトで。近藤社長にはメールで。共有化はしない。（＊この図は、筆者が考案たものです。） 31

32. 報告書作成方法結論： ① BIツールである、バランス・スコアカード・ソフトウェアは、視覚的に、財務視点、顧客視点、革新視点、内部視点の４つを表すので、上級マネジメントへの報告形式としてよく用いられる。 ② 近藤社長は、戦略の意思決定者なので、バランス・スコアカードを、芹沢会長は、忙しいので、○だけでよい。 Yuko Soma – Case 16 - 2 ここが、プレゼンの終わりです。芹沢会長殿 Seeについて、以下の通り、報告させていただきす。ご質問がありましたら、ご連絡くだるようお願い致します。以上 ○ △ × 財務視点顧客視点革新視点内部視点 Hi. Mr. Kondo Bla bla bla.... Warm regards. ステップ3 報告先によって、言語・内容・媒体を変える。（＊この図は、筆者がl考案したものです。）（＊この図は、筆者がl考案したものです。） 32

33. プロジェクト管理プロセスを利用するメリットについてケーススタディ OSA 1 の要約：以下をITILで解決してほしい。 ① サービスオペレーション業務は、手順書に従うルーチンワークとして行なってきた。 ② 手順書違反に関しては、厳しくしていた。 ③ ITILでは、サービスオペレーションにも、プロジェクト管理プロセスを利用すると良いと言っているが、そのメリットが知りたい。 ITILの基礎1: サービスライフサイクルとプロジェクトと共通機能との関係は以下の通りである。 Yuko Soma – Case 1 - 1 ここが、プレゼンの始まりです。サービストランジションサービスデザインサービスオペレーション技術管理サービスストラテジ IT運用管理アプリケーション管理サービスデスクサービスマネジメントプロジェクト ② サービスデスクは、プロジェクトを通じて、サービスデザインと、サービストランジション・サイクルに関わる。 ① サービスデスクの仕事は、ルーチンワークだけではない。 ③ サービスデスクは、プロジェクトを通じて、共通機能と協業する。（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 33

34. ITILの基礎2: プロジェクトとは・・・ ① インフラストラクチャの大規模なアップグレード、あるいは新しい、または変更された手順の展開において、毎回異なる目的を持ち、始期と終期のあるタスクのことである。 ② コントロールを改善し、コスト、リソース管理ができるようになる。メリット：サービスデスクに、正式なプロジェクト管理を採用することにより、下記が実現されるとITILは言っている。まとめ： ① 手順書に大きな変更があるだけでも、予算金額によっては、プロジェクトになるので、従来の方法と矛盾しない。 ② スタッフのモチベーション、技術スキル、コミュニケーション能力が向上する。 ③ 他の機能、他のサービスライフサイクルと関わることで、運用段階になってからの手直しを削減することができ、事業目標に貢献できる。 ④ プロジェクトの成功に重要なのは、上級マネジメントの後援であり、プロジェクトのリスク、想定事項、制約、リソース、コストについて合意すべきである。 Yuko Soma – Case 1 - 2 ここが、プレゼンの終わりです。プロジェクト管理プロセスを利用するメリットについて 1. 定量化他のITグループと事業は、運用チームによる貢献を定量化することが容易になる。 2. 資金化従来、正当化が困難だった通常業務に対して、資金を獲得することが容易になる。 3. 信頼一貫性が増し、品質が改善され、顧客へのインパクトが小さくなることで、運用グループの信用度が上がる。 34

35. インシデントの優先付け方法についてケーススタディ OSA 1の要約： ① 緊急度の高いインシデントを先に処理するか、インパクトの大きいインシデントを先に処理するかで意見が分かれている。 ② 具体的に、例をあげて、どのように優先度づけしたらよいか提示してほしい。 ITILの基礎1: インシデントとは・・・ ITサービスい対する計画外の中断やITサービスの品質の低下、または、ITサービスにまだインパクトを与えていないCIの障害である。 ITILの基礎2: 優先度の付け方・・・ ITILでは、インシデントの優先度付けは、事業にとって、どれだけ早く解決が必要であるかという緊急度と、そのインシデントが事業に与えるインパクトの程度の両方のバランスを考慮して決定するとよいとしている。導入へのステップ: ステップ1 問題の把握と、利害関係者の識別問題：インシデントの優先付け方でもめている。利害関係者：意見が割れている部内のグループ、ユーザ Yuko Soma – Case 2 - 1 ここが、プレゼンの始まりです。 35

36. インシデントの優先付け方法についてステップ2 もめた場合は、ITILの言う通りの方法で、優先付けをし、実践してみる。結論 : ① ユーザに対する平等性を保つためにも、優先度付けは重要だが、コミットメントではない。 ② VIP対応は優先するが、これは、上級マネジメントに特定の問題が知られたからといって、優先度をあげることは意味しないので、注意すること。 ③ SLAを満たすためだけの目的で、チケットをクローズせず、ユーザをサポートすることを主目的とする。 Yuko Soma – Case 2 - 2 ここが、プレゼンの終わりです。インパクト緊急度高中低高 1 2 3 中 2 3 4 低 3 4 5 優先度コード説明 SLA（仮） 1 致命的 1時間以内 2 高 8時間以内 3 中 24時間以内 4 低 48時間以内 5 計画に組み込む計画に応じて緊急度の要因：そのインパクトが起きるまでの時間がどのくらいあるか。インパクトの要因： 1. 生命や健康にかかわるリスク 2. 影響を受けるサービスの数、ユーザ数 3. 財政上の損失のレベル 4. 事業の評判への影響 5. 規制上、または法律上の意版 VIP対応: 指定されたVIPには、優先度を高くするなど、強化サービスにし、その旨合意して、サービスカタログに記載するよい。ITSMツール上で、VIPが誰かが明確になるように表示させる。 (具体例) 1000人中5人が使用しているアプリケーションの速度が遅くなり、上級マネジメントがそのことに懸念を示しているが、入力開始予定日まで7日ある場合は、優先度は5となる。（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 36

37. 委託サービスデスクの委託内容と料金設定までの流れケーススタディ OSA 4 の要約： ① サービスデスク機能を外部委託しており、1コールにつき、3000円を請求されているが、どこまでを委託するかも含めて、今後、料金設定をどうしたらいいかわからない。 ② ITILでは、どの管理を導入すればよいか。 ③ これらの問題を解決するにあたり、担当する管理は何か、また、調整役となる他の管理プロセスとは、何を取り決めておけばいいかを教えて欲しい。解決へのステップ：ステップ1 問題の把握と複数の解決案の策定問題：価格設定があいまいなのを解消し、そのための管理プロセスを導入したい。解決案：問題を分析して、適切な管理プロセスを導入するとよい。ステップ2: 委託範囲が不明確 - どこまで委託するのか？ Yuko Soma – Case 4 - 1 ここが、プレゼンの始まりです。レベル分類委託例レベル1 簡単な問い合わせ ○ 「サービスデスクは何時まで受け付けていますか？」等レベル2 簡単なサービス要求 × カートリッジ交換。プリンタの紙づまり。プロジェクタ、ポリコムの設定。レベル3 低リスクで、低コストの小さな変更要求 ○ 座席変更による、PCの移設と、アクセス要求； DLへの追加などアクセス管理から権限移譲されたもの等レベル4 イベント管理からエスカレーションされてきたインシデント ? 例外イベントの調査。レベル5 問題管理にエスカレーションと調整が必要な、複雑なインシデント ? 根本原因の解明が必要なトラブル、変更を伴うトラブル。ユーザへの協力依頼、定期的なフィードバックが必要。問題の分析例）レベル別にチャージできないか？（＊この図は、筆者が考案したものです。） 37

38. 委託サービスデスクの委託内容と料金設定の流れステップ2 以下のプロセスを活用する。サプライヤ管理が担当し、ITサービス財務管理、サービスレベル管理などのプロセス、法務部、購買部と調整をする。ステップ3 プロセスをレビューし、改善する。まとめ： ① サプライヤ管理が、他のプロセスと協業して、委託する実現要求サービスと、そのSLRをまとめる。、② サプライヤ管理は、すべてのサプライヤ契約とその合意が、ビジネス・ニーズに整合していることに責任をもつ。 Yuko Soma – Case 4 - 2 ここが、プレゼンの終わりです。サービスポートフォリオ管理アクセス管理インシデント管理 SLMとサプライヤ管理が協力して、サービスデスクの委託範囲について、SLAとSLR におけるサービスレベル目標値および責任に合意する。すべての支援サービスとその詳細、および関係が、サービスポートフォリオ内に正確に反映されているようにする。サービスレベル管理サプライヤ管理 ITサービス財務管理資金調達に十分な財源を提供し、購買および調達事項に関して財務関連の助言と手引きを提供する。法務部購買部（＊この図は、筆者が考案したものです。） 38

39. アクセス権の変更のトリガと、アクセス管理者の責任ケーススタディ OSA 9 の要約：以下をITILで解決してほしい。 ① 現在、全てのIDに、全てのアクセス権が付与されている状態である。 ② 問1: どのような場合にアクセス権の内容を変更するべきか、具体的な例示してほしい。 ② 問2: アクセス管理者の責任を明確にする方法について、図解で説明してほしい。問1: 下図の4つの場合に、アクセス権の内容は変更される。 Yuko Soma – Case 9 -1 ここが、プレゼンの始まりです。要求の受け取り変更要求アクセス権の変更人事上の要求（人事部または部門長）アプリケーションスクリプトまたは要求サービス要求有効なユーザか、有効な要求か？アクセス権の記録と追跡昇進、異動、出向、解雇、入社、退職による、アカウント等の作成、停止、変更。検証セキュリティ管理情報システム必要に応じて、ステージングサーバから、アプリケーションをダウンロードするなど、事前に許可されたスクリプトの実行・要求実現システム（買い物かご）を介して提出されるサービス要求。 RFCの提出により、プロジェクトの一環として、大人数のユーザ権限の更新。 39 （＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。）

40. アクセス権の変更のトリガと、アクセス管理者の責任問2: アクセス管理者の責任を明確にする方法 ① 事業関係管理が、法務部からの要望により、アクセス・コントロールについてのビジネス・ケースを作成する。 ② サービス・ポートフォリオ管理が、アクセス・コントロールについての、サービス・モデルを作成して、SDサイクルに渡す。 ③ デザイン・コーディネーションが、サービスの妥当性確認およびテストに、サービスデザインパッケージを渡す。 ④ アクセス管理者の責任が記載された文書をSOマネージャに渡し、サインさせる。まとめ： ① アクセス管理は、どのITサービスに誰がアクセスするかに対して、決定権は持っておらず、全て、情報セキュリティ管理プロセスの方針に基づいて、代行しているにすぎない。 ② 今のままでは、コンプライアンス違反なので、まずは、アクセス管理についての、サービス要求モデルを作成し、グループを作成し、サービスディレクトリに反映し、アクセスをモニタリングし、定期的に、アクセス管理について、測定すべきである。 ③ コンプライアンスの徹底が、事業目標なので、できるだけ、自動化すべきであり、セキュリティ・インシデントに備えて、アクセス管理は、インシデント管理との連携が必須である。 Yuko Soma – Case 9 - 2 ここが、プレゼンの終わりです。ビジネス・ケースサービス・モデルサービス・デザイン・パッケージアクセス管理者の責任が記載されたドキュメント一式（＊この図は、筆者が考案したものです。） 40

41. イベント管理とインシデント管理の関係ケーススタディ OSA 10 の要約：イベントの種類について、イベントとインシデントとの関係を、お弁当作りを例にして、説明してほしい。 ITILの基礎：イベントとは・・・ ① イベントには、下図の3種類があり、右にいくほど、対処が必要な、重要なイベントである。 ② 通常、バッチのスケジューリング、テープ・バックアップ、ストレージ容量チェック、可用性レベルなど、インフラストラクチャ全体のイベントをモニタリングする必要があるため、サービスデスクだけでなく、IT運用管理にも関係が深い。 Yuko Soma – Case 10 - 1 ここが、プレゼンの始まりです。情報イベント例外イベント警告イベント a) スケジューリングされた作業負荷が完了した。 b) ユーザがアプリケーションを使用するためにログインした。 c) 電子メールが対象とされた受取人に届いた。 a) サーバのメモリ使用率が、許容可能なパフォーマンス・レベルの上限 5%以内にまで達している。 b) トランザクションの完了に、通常より、10%長い時間がかかっている。 a) ユーザが不正なパスワードで、アプリケーションにログオンしようとした。 b) ビジネス・プロセスで、事業による更なる調査を必要とする、例外を示す異常な状況が発生した。 c) 装置のCPUが、許容できる使用率を超えている。 d) トランザクション処理が終わらない。ご飯メインの海老フライどうでもよいパセリ低重要度高（＊この図は、筆者が考案したものです。） 41

42. イベント管理とインシデント管理の関係： ① 海老フライは、必須の”例外イベント”として、インシデント管理にエスカレーションされる。 ② ご飯である”警告イベント”がインシデントなる可能性は、めったにないが、あれば欲しい。 ③ どうてもよいパセリの”情報イベント”は無視してよい。まとめ： ① ITSMツールの設計で、適切なフィルタリングのレベルを設けると、人の介入が減り、コストを最小化できる。 ② すべてのコンポーネント(CI)を、イベント管理に組み込むように、ITSMを設計する必要がある。 ③ イベント管理の自動化は、サービスデスクだけでなく、IT運用管理の仕事にも必須である。 ④ イベントは、種類によっていつまでの保存が必要か、コンプライアンスなどの利害関係者と話し合う。 Yuko Soma – Case 10 - 2 ここが、プレゼンの終わりです。イベント管理とインシデント管理の関係例外イベントフィルタリング情報イベントインシデント管理イベント管理フィルタリングの設定次第では・・・・無視最低限、メインの海老フライがないと・・・可能であれば、ご飯も！参考程度 ITSMツール：インシデント・チケットが自動起票され、SDキューにアサインされる。→要「人の介入」 ITSMツール：インシデント・チケットは自動起票され、自動的にクローズされる。イベントイベントイベント警告イベント（＊この図は、筆者が考案したものです。） 42

43. サービスデスクの形態と欠点についてケーススタディ OSA 13 の要約：以下をITILで解決してほしい。 ① 将来の業容拡大と、低コストであることから、オフショアでのサービスデスク業務も考えている。 ② サービスデスクの形態と欠点、そしてその欠点をカバーする方法を教えてほしい。 ITILの基礎: サービスデスクの形態には、以下の4種類があり、組み合わせるとよい。 Yuko Soma – Case 13 - 1 ここが、プレゼンの始まりです。特徴利点欠点ローカル・サービスデスク対象ユーザ・コミュニティと、同じ場所か物理的に近い場所に存在する。コミュニケーションに有利で、その存在がはっきりしているため、一部のユーザには好まれる。コール量と到着率が少ない場合には、待機時間が多くなるため、非効率で高価になることも多い。中央サービスデスクスタッフを1つ以上の中央サービスデスク構造にまとめることによって、複数のサービスデスクを単一の場所に統合し、その数を減らすこともできる。効率と費用対効果を向上して、より少ないスタッフ数でより大量のコールに対応することができ、イベントの頻繁な発生による業務への更なる精通から、スキルレベルの向上につながることもある。中央サービスデスクから指示をするものの、結局、ローカル・サービスデスクの配置は、物理的なサポートのために必要となってしまう。バーチャルサービスデスク実際には、要員が複数の地域や別部門に分散していても、単一の中央サービスデスクがあるかのような印象を持たせる事ができる。在宅勤務、2次サポートグループ、オフショアリング、アウトソーシング、または、これらの任意の組み合わせができるので、効率と費用対効果がよい。サービス品質とカルチャにおける一貫性と画一性を確保するために、実現手段が必要になる。フォロー・ザ・サン物理的に分散した2つ以上（通常は、アジア、欧州、米国）のサービスデスクを組み合わせて、24時間体制のサービスを提供。どの地域のサービスデスクもシフト勤務をする必要がなく、比較的低コストで、24時間対応が可能。共通のプロセス、ツール、情報の共有データベース、カルチャなどに対する保護手段を準備する必要がある。 43

44. サービスデスクの形態と欠点についてステップ1 問題の把握と解決案の策定問題：オフショアでのサービスデスクを考えているが、その欠点があれば、回避したい。解決策： 4種類の組み合わせとなる。ステップ2 以下のようなサービスデスク組織を作る。「サービス品質とカルチャにおける一貫性と画一性を確保するために、実現手段が必要になる」という欠点をカバーするには・・・ ① 日本語話者の人口が多く、人件費の安価な地域に、ニアショア先を見つける。 ② 日本カルチャとサービス品質のトレーニングを計画する。 ③ 一貫性をもたせるため、全ての詳細なドキュメントを用意する。 ④ ITサービスマネジメントツールを導入して、日本へのエスカレーションの仕組みをつくる。ステップ3 欠点がカバーできているかレビューし、改善する。結論： ① どの形態のサービスデスクにも欠点はあるので、利点のほうが上回ればそれでよい。 ② 特にニアショア化には、トレーニングとツールの導入と適切な運用に重点をおかなければ、かえってユーザの満足度が下がる。 Yuko Soma – Case 13 - 2 ここが、プレゼンの終わりです。 44

45. BCPの策定ケーススタディ OSA 15 の要約：以下を、ITILで解決してほしい。 ① 企業合併の秘密が漏洩してしまった。 ② 緊急役員会議で使う、今回の情報漏洩事故に対処する、短期的な対策と、長期的な対策を作成してほしい。解決へのステップ：ステップ1 問題の把握と、解決案の策定問題：情報漏洩事故が起きたときの対応策がなかった。解決案：今回は、事業顧客を巻き込んで、対処する必要がある。ステップ2 短期的な対応、中期的な対応、長期的な対応をとる。短期的な対策：直ちに、機密情報をネットワーク接続から退避させ、その部屋への、外部からの物理的な侵入を禁止する。中期的な対策： ① 機密情報が入っていたマシンへのアクセス履歴を調べる。 ② 外に漏洩しているデータが他にもないか、技術管理プロセスのメンバーに調べてもらう。 ③ ビジネス・インパクト分析、リスク分析を行ない、事業への影響と損害を算出する。 Yuko Soma – Case 15 -1 ここが、プレゼンの始まりです。 45

46. BCPの策定 Yuko Soma – Case 15 - 2 ここが、プレゼンの終わりです。長期的な対策： ① BCPを策定する。 ② ITSCMを導入する。 ③ 情報セキュリティ管理を導入し、セキュリティ方針を作成する。 ④ アクセス管理を導入し、効率的に、ユーザID認証、アクセス許可、ユーザIDステータス追跡を行なう。ステップ4 プロセスをレビューし、必要に応じて、改善する。結論： ① BCMが無かったことが、今回の事業存続の危機となったことを、CEOは、十分反省する。 ② 全ての用意ができたら、インシデント管理、アクセス管理は、それに従って、連携して、サービス・オペレーション業務を行なう。 d) アクセス付与の自動化 a) モニタリング・ツールの導入 c) ディレクトリ・サービス技術の導入 b) 役割カタログの導入 e) 人事部との連携（＊この図は、筆者が考案したものです。） 46

47. ケーススタディ OSA 16 の要約： itＳＭＦ版は本文の後に、付録A～付録Iの頁があるが、付録B(OSA pp. 214 – 229 “サービスオペレーションのコミュニケーション”)の内容をまとめてほしい。解決へのステップ：ステップ1 方針の決定と、上位との合意 ① SO段階におけるコミュニケーションが、すべてのチーム、および部門が関与する、標準的な活動を実行できるように計画する。 ② このコミュニケーションの内容、種類、および形式を定める。日系S社の事例：サービスオペレーションのコミュニケーション Yuko Soma – Case 16 -1 ここが、プレゼンの始まりです。事業顧客本部・ユーザ (主に）運用管理東京大連モスクワストックホルムシェアードサービス子会社 (主に) 技術管理・アプリケーション管理ニュー・メキシコ APAC時間 EMEA時間アメリカ時間 ⑨シフト間におけるミュニケーション ⑦パフォーマンス報告 ③プロジェクトにおけるコミュニケーション ④変更におけるコミュニケーション ⑤例外に関するコミュニケーション ②緊急事態に関するコミュニケーション ⑧グローバルなコミュニケーション ⑥ユーザおよび顧客とのコミュニケーション ①ITサービスにおけるコミュニケーションサービスデスク（＊この図は、筆者が考案したものです。） 47

48. サービスオペレーションのコミュニケーション Yuko Soma – Case 16 - 2 ここが、プレゼンの終わりです。種類（抜粋）目的頻度対象者内容状況/情報源 ③プロジェクトにおけるコミュニケーション ①プロジェクトの利害関係者からの指示を得ること。 ②個人、またはチームに作業を割り当てることなど週次のプロジェクト・ミーティングをモスクワにいる、プロジェクト・マネージャが開催。 ①プロジェクト・マネージャ、運営管理スタッフ、調整スタッフ ②プロジェクト後援者 ③ニュー・メキシコのサプライヤなどプロジェクトによって構築されているソリューションに対する要件の収集など ①プロジェクト憲章 ②プロジェクト予算 ③要件記述書 ④プロジェクト・スケジュールなど ⑧グローバルなコミュニケーション ①明確な戦略と方針の整備 ②カルチャや言語が違っても、顧客満足度を落とさないこと ①各シフトの引き継ぎ時 ②随時、ホワイトボードへの書き込みカルチャに関する支援者および調整者など複数の国で使用されるドキュメントなどの書面によるコミュニケーションなど ①国際労働法の知識を持ったリーガルスタッフ ②3カ国語のスキルをもったサービスデスクスタッフなど ⑨シフト間でのコミュニケーション APAC -- > EMEA  アメリカ時間の引き継ぎが円滑であること。 ①各シフトの引き継ぎ時(朝9時、夕方5 時、夜中の0時の3 交代) ②オンコール時 ①各リジョンのシフト・リーダ ②オンコール当番のスタッフ ①運用に関する要約レポート ②未解決のすべての例外およびアラートの要約 ①各リジョン・キューののオープン・ログ ②マイクロソフト・リンクによる、ビデオ・コミュニケーションステップ2 要員の役割・権限・責任を決める。まとめ： ① ITILのサービスオペレーションは、グローバルな環境を前提としている。 ② 様々なコミュニケーションをとることで、文化、カルチャ、言語、時差などの制限事項を、極力、排除することが可能となる。（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 48

49. サービス要求のヘルプデスクでの振り分けについて Yuko Soma – Case 1 - 1 例1）箱館・五稜郭ツリーを建設してはどうか例2) セキュリティの全面的見直しをしてほしいアクセス管理プロセスサービスデスク機能では扱わないので、エスカレーションする例）変更届けはどの様に出せばよいかユーザからの入電サービスデスク機能例）異動してきた部員に、アクセス権を付与してほしいソフトウェアのインストール要求アクセス権の追加事業やITサービスに関わる大掛かりな要望例）業務で必要になったソフトウェアをインストールしてほしい変更管理プロセスサービスデスク機能で処理する要求実現プロセスサービスの取得に対する支援ここが、プレゼンの始まりです。事業関係管理プロセスケーススタディ RCV 1 の要約：以下をITILで解決して欲しい。 ① サービスデスクとインシデント管理を導入し、全員が、交代で、本来の業務から離れて行なうことになった。 ② プリンターの用紙サイズを変更したい、五稜郭ツリーを建設したいなど、大小さまざまな要求が、ユーザから来てしまった。 ③ 今は個人の判断で適宜、処理しているが、ユーザからの要求を、しかるべき組織で、しかるべきルールで、処理したい。 ITILの基礎: サービス要求とは・・・ユーザから、IT組織に依頼がある、さまざまな種類の要求を指し、具体的には、単純な情報の要求、頻度は高いが、低リスクで、低コストの小さな変更要求のことである。（＊この図は、筆者が考案したものです。） 49

50. サービス要求のヘルプデスクでの振り分けについて ITILの基礎2: 要求実現プロセスとは・・・ユーザからのすべてのサービス要求のライフサイクルを管理することに、責任を負うプロセスである。解決へのステップ: ステップ1 方針の決定と上位との合意ヘルプデスクで受け付けられたものは、どの機能、プロセスに振り分けられるのがよいかについて、方針を決定し、上位と合意する。ステップ2 プロセスの活動・手順を決める。あらゆるリクエストに対応した、プロセスと機能を決め、更に、要求実現プロセスと、アクセス管理プロセスが処理するリクエストに関しては、全てに関して、要求実現モデルを事前に決めておく。 ①実現する許可 ②どの機能が実施するのかをレビュー ③要求実現モデルに従って実施 ③ユーザの了解を得て、クローズする。まとめ： ① リクエスト内容の分類、処理手順を事前にとり決めることにより、サービスデスク機能の誰が担当しても同じ成果が得られることが、ITILでは推奨されている。 ② 要求実現プロセスか、アクセス管理プロセスか、変更管理プロセスか、事業関係管理プロセスのどれで扱うべき問題か振り分ける一定の基準を、文書化し、SKMSに保存する。 ② 要求実現モデル化ができたら、ウェブ注文インターフェイスを活用すると、変更手順が一部自動化され、上記の入電から開始の場合よりも、迅速に要求実現できることで、顧客満足度が上がる。 Yuko Soma – Case 1 - 2 ここが、プレゼンの終わりです。リクエスト内容処理するプロセス機能実現要求モデル MS Access 2013をインストールしてほしい。要求実現プロセスサービスデスク ①サービスカタログにあるか確認、②ライセンス数の確認、③なければ、請求 ④請求が承認されたら、リモート・インストールの準備 ⑤プッシュアプローチ、⑥ライセンス数の変更をCMSに記録。セキュリティ方針全体を見直して欲しい変更管理プロセス技術管理 n/a （＊この図は、筆者が考案したものです。） 50

51. 変更管理をコントロールする方法についてケーススタディ RCV 2 の要約：以下をITILで、解決してほしい。 ① システム移行後の初期トラブルの頻発、緊急変更の実施の順序についての争いがある。 ② CABの実施基準が不明瞭である。 ③ 顧客からのリクエスト内容の矛盾による変更の再変更がある。解決策: 変更管理プロセスの導入により、許可された変更が、優先度づけ、計画、テスト、実施、文書化、レビューされるモデルを作成することで解決できる。導入のステップ: ステップ1 認知向上活動まず、「ITサービスとは、顧客への価値の最大化を目標とし、変更管理は、事業にも関わっている」ことを、IT 内と顧客に周知させる。 Yuko Soma – Case 2 - 1 ここが、プレゼンの始まりです。 51

52. 導入のステップ: ステップ2 手順を決め、文書化する。緊急の変更と通常の変更の場合は、下図のモデルとなる。ステップ3 プロセスをレビューし、必要に応じて、改善する。まとめ: インシデントの発生、変更の中断、手直しの問題が解決できているかを確実にすることが、顧客満足度の向上に貢献する。 Yuko Soma – Case 2 - 2 変更管理をコントロールする方法についてリスクとインパクトと緊急度のレベルにより、承認者が決まる。優先度づけここが、プレゼンの終わりです。変更をアセスメント変更を立案変更の許可変更の実施変更をレビュー Plan SeeDo CAB ECAB 変更マネージャ役員（＊この図は、筆者が考案したものです。） 52

53. リリース管理と展開管理のプランの重要性についてケーススタディ RCV 4 の要約：大規模リリースの手順書は、PDAのどこに重点をおくべきか、また、重要なポイントひとつを具体的に、ITILに基づいて、提示してほしい。提案: ITILでは、P (計画) が開始地点と考えられており、Pに力点をおくと、デミングサイクルがうまく作動し、コストを最小化して、リリース管理と展開管理を実現する。 Yuko Soma – Case 4 - 1 ここが、プレゼンの始まりです。 Plan DoCheck Act 53

54. 比較： PDAのどこに重点を置くかで下図の違いがでる。重要なポイント: ① Pに重点を置いた場合は、改善すべき点が最小化される。 ② 反対に、Aに重点を置いた場合は、改善すべき点が多く、コスト高になり、時間もかかってしまう。 ③ これでは、事業顧客の合意も得られないし、満足度も得られない。よって、コストを正当化できない。まとめ: リリース後のトラブルを防止するためにも、いくつもで、改善点を出すのではなく、リリースに着手する前に、P の計画段階で、リリース中、リリース後のトラブルを防止しなければ、大きな事故を防ぐことが難しい。 Yuko Soma – Case 4 - 2 リリース管理と展開管理のプランの重要性についてここが、プレゼンの終わりです。 Pに重点を置いた場合 Aに重点を置いた場合計画立案計画立案実施測定・レビュー改善実施測定・レビュー改善改善すべき点 P P D A C C A 効率的で、改善コストを最小化！手戻りが多くなり、改善コストも膨大に・・改善すべき点（＊この図は、筆者が考案したものです。） 54 D 改善すべき点改善すべき点

55. サービスの妥当性確認およびテストによる、DBの遅延原因の特定と、変更評価による、評価方法ケーススタディ RCV 5 の要約： ① 多品種、多数の原産地などの複雑な情報をDBに一元化したが、この事業のVBFとなるDBのユーザサービスに遅延が発生してしまっており、事業の存続にかかわる問題となっている。 ② その原因となる要素を特定し、その要素の評価基準を、ITILに基づいて設定してほしい。解決策: ITILの妥当性確認およびテスト・プロセスを導入し、変更がある場合は、リリース管理および展開管理とは中立の立場で検証することにより、インシデントの原因となる要素を特定し、変更評価プロセスにより、4つの評価レポートを提出して、評価すべきである。 ITILの基礎: 妥当性確認およびテスト・プロセスとは・・・・・ ① サービスの品質保証を行ない、有用性を提供することの妥当性を確認する。 ② テスト・プロセスの実施により、エラー、リスクを識別する。解決へのステップ: ステップ1 問題の把握と利害関係者の特定現状： ① VBFとなるDBのユーザサービスに遅延が発生。 ② 協力企業のユーザと、消費者が被害を受けており、事業顧客の存続が危ぶまれている状態。 Yuko Soma – Case 5 - 1 ここが、プレゼンの始まりです。 55

56. サービスの妥当性確認およびテストによる、DBの遅延原因の特定と、変更評価による、評価方法 Yuko Soma – Case 5 - 2 テスト計画立立案と設計許可済みの変更評価済みの設計テスト計画とテスト設計の検証変更評価テスト後のクリーンアップとクローズ終了基準とレポートの評価テストの実施テスト環境の準備解決のステップ: ステップ2 下図のプロセスに従って、妥当性をテストする。妥当性確認およびテストステップ3 変更評価プロセスで、遅延の原因となる要素を特定し、その要素を評価する評価レポートを作成し、レビュー、改善する。評価レポート変更評価によって、作成されるレポートで、右の 4つのから成る。これは、変更管理に渡される。 1. リスク・プロファイル 2. 逸脱レポート 3. 推奨事項 4. 検証記述書ここが、プレゼンの終わりです。（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 56

57. ケーススタディ RCV 6 の要約： ① RAID構成に依存しすぎていたため、テープバックアップをとっていなかったので、データが消滅してしまった。 ② 手作業でデータを入力した結果、経費が莫大となった。 ③ このような事態が起きないよう、ITILで解決してほしい。解決策: ① 事業の存続にかかわるような問題となっていることから、事業顧客と、ITSCMプロセスが連携し、BCMを策定すべきである。 ② データは顧客にとって大事なので、日次でデータバックアップをとり、遠隔地で保存するバックアップ戦略だけは早急に決める。解決のステップ: ステップ1 関係部門のまきこみこの問題は、ビジネス・プロセスに関わるので、顧客側に、事業継続計画を作成してもらうよう要請し、ITSCMプロセスが協力する。 Yuko Soma – Case 6 - 1 ここが、プレゼンの始まりです。開始 BCM ITSCM 要件と戦略事業継続性戦略  方針の設定  適用範囲の定義  プロジェクトの立上げ  ビジネス・インパクト分析  リスク・アセスメント  ITサービス継続性戦略リスク：データの喪失脅威：技術的障害 BCMとITSMプロセスで、バックアップ戦略（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 57

58. ステップ2 ビジネス・インパクト分析を行なう。 ITサービスの損失が事業に与えるインパクトを定量化することを目的とする。ステップ3 リスク・アセスメントを行なう。 ITサービスの継続性に対する潜在的な脅威と、その脅威が現実になる可能性を識別することを目的とする。まとめ：ステップ4 バックアップ戦略により、災害時だけでなく、運用上の障害後のデータ復旧も確実になる。ステップ5 BCM導入後は、テストをし、適宜、改善していく。 Yuko Soma – Case 6 - 2 ここが、プレゼンの終わりです。 BCMとITSMプロセスで、バックアップ戦略項目詳細損害または損失となりうる形態収入、追加コスと、傷ついた評判、信用の喪失、競争上の優位性の喪失、法律および安全規制の違反 etc.・・・損害や損失の程度が、いかに増大するか、また中断が最も申告となる時期日、週、月、または年の中の時間最小限のレベルで復活させるべき時間スタッフ配置、スキル、設備、ITサービスを含むサービス全ての必要なビジネス・プロセス、サポートスタッフ、設備、およびサービスを完全に復旧させるべき時間各ITサービスに対する、相対的な事業復旧優先度リスク脅威内部ITシステム/ネットワークなどの損失火災、停電、環境災害、事故による破損、壊滅的な障害、低品質のソフトウェアデータの喪失技術的障害、人的エラー、攻撃アプレットなどのウィルス 58

59. 変更管理プロセスによる、最適なSDP開発ケーススタディ RCV 9 の要約：別の派閥グループが既に開発したSDPによる、E-learning製品開発を、ＩＴＩＬを利用して合理的に阻止し、自グループによる、ITILに即した、よりよい方法で同製品を提案したい。要望：どうしたら、両派閥が納得できるよう、阻止できるか、提案してほしい。解決策: ① SDP開発完成の前に、変更管理プロセスを経由することにより、より確実なSDP開発ができ、優位性をもつ。 ② 別グループのSDPは、このプロセスがなかったとしたら、リスクの高い移行計画となるので、中止すべきであると説明する。その根拠1: ITILでは、変更許可プロセスからの変更許可を下記の段階等で、受けるべきと述べている。 ① サービスデザイン活動を実施する前 ② サービスデザインが完了した後で、SDPの登録を許可するとき Yuko Soma – Case 9 -1 ここが、プレゼンの始まりです。 SDP登録サービスデザイン活動実施変更管理変更管理変更許可変更許可（＊この図は、筆者が考案したものです。） 59

60. 変更管理プロセスによる、最適なSDP開発その根拠 2: 変更管理によって、以下のインパクト・アセスメントが行なわれずに、SDP開発を行なうと、稼働中のサービスに対するリスクと利点のバランスを把握できない。まとめ： ① サービスデザイン活動実施前と、SDP登録前に、変更管理プロセスの変更許可を得ていなければ、事業に与えるリスクを回避できない可能性がある。 ② 従って、今回のSDP開発を中止にすべきであることは、ITILに従うと、明白である。 Yuko Soma – Case 9 - 2 7つのR Raised - 変更を提起したのは誰か? Reason - 変更の理由は何か？ Return - 変更の見返りは何か？ Risk - 変更のリスクは何か？ Resource - 変更に必要なリソースは何か？ Responsible - 変更の構築、テスト、実施の責任者は誰か？ Relationship - この変更と他の変更との関係は何か？ここが、プレゼンの終わりです。（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。） 60

61. ST管理のプロセス・マネージャの役割と責任についてケーススタディ RCV 10 の要約： ITILに従った、STの導入をするにあたり、STの各プロセスマネージャの役割と責任を明確にしたい。共通する部分と、固有の部分について、説明してほしい。前提条件：・図の組織図のように、各プロセスマネージャは位置している。・プロセス・マネージャは、物理ロケーションごとに設置し、複数いることがある。・プロセス・オーナと兼任していることがある。共通：全プロセス・マネージャは、各プロセスの運用上の管理に対して、説明責任を負う。更に、主に、以下の説明責任がある。・サービス・オーナおよびその他のプロセス・マネージャと協力して、サービスがスムーズに稼働するようにする。・必要とされる役割に、人材を任命し、管理する。・改善の機会を分析し、改善する。 Yuko Soma – Case 10 - 1 プロセス実務者 CIO プロセス・オーナ指示ソウル指示プロセス・マネージャプロセス・マネージャここが、プレゼンの始まりです。プロセス実務者台北指示指示台北アムステルダム東京上海（＊この図は、筆者が考案したものです。） 61

62. ST管理のプロセスマネージャの役割と責任について個別の役割： Yuko Soma – Case 10 - 2 プロセス・マネージャ個別の役割移行の計画立案およびサポート STの活動およびリソースについて、予算業務と会計業務を行なう。変更管理変更スケジュールとサービス停止計画を維持する。変更評価評価レポートと、臨時の評価レポートを送れずに提供し、変更許可委員が、意思決定の支援にそれらを利用できるようにする。サービス資産管理および構成管理 IT固定資産管理について、組織に対して、説明責任を負う。ナレッジ管理ナレッジを提供するよう、推進する。リリース管理および展開管理変更許可がされるように、必要なものを準備する。サービスの妥当性確認およびテストリリース管理および展開管理、その他のチームのテストを検証する。ここが、プレゼンの終わりです。個別の役割まとめ： ① プロセス・マネージャは、お互いに協力しなければならない。 ② しかし、リリース管理および展開管理、サービスの妥当性確認およびテストの両マネージャは、テストに関して、公正な立場をとらなければ、正しくテストを検証することにならない。 ③ また、変更管理管理と、変更評価管理の両マネージャは、変更評価に対して、公正な立場をとらなければ、正しく変更できない。（＊この図は、筆者が考案したものです。） 62

63. ナレッジ管理プロセスで、DIKWを構成管理に取り入れるケーススタディ RCV 11の要約：各事業ユニットが所有している多彩な情報を共有するため、各事業ユニットのDIKWを構成管理に取り入れる方法を提示してほしい。導入のステップ: ステップ1 認知向上活動・ナレッジの共有は、ビジネス・プロセスに貢献することを、IT内と顧客に周知させ、IT部門内外から、データ、情報、ナレッジを得られるよう協力を呼びかける。・ナレッジ管理プロセス・マネージャは、ナレッジの収集を推進しなければならない。 Yuko Soma – Case 11 - 1 ここが、プレゼンの始まりです。 63

ITIL 2011 Edition Case Study 【Continuous Study】

ITIL 2011 Edition Case Study 【Continuous Study】

Recomendados

Mais conteúdo relacionado

Similar a ITIL 2011 Edition Case Study 【Continuous Study】

Similar a ITIL 2011 Edition Case Study 【Continuous Study】(20)

Mais de Jerimi Soma

Mais de Jerimi Soma(20)

ITIL 2011 Edition Case Study 【Continuous Study】

Notas do Editor