ITIL2011 to ITIL4 transition baseline guidance 【Continuous Study】

1. 1 Implementation of ITIL2011 Framework for Boise Potato Firm 　　　　　　　　　　　　　～　ITIL 2011レビュー記録　2019年11月4日更新版　〜はじめに ITILの起源は、英国にて1986年であると言われるため、30年を超える歴史がある。ITIL4コア書籍オンライン版が2019年10月にベータ版として出版されたため、 ITIL2011をふりかえってみる。 ITIL2011との違いは、アジャイル、クラウドコンピューティング、SIAM、DevOps、AI等が加わることにより、より、現代の実態に即したフレームワークとなっていること、ITIL2011で対象であった法務部、財務部などのIT関連部門のためのフレームワークではなく、マーケティング部、営業部を含む組織全体、IT以外のサービス全体を対象にしたことである。　ITIL2011の各ライフサイクルの「事業に対する価値」は以下の通りである。 (1)サービスストラテジ　(SS) サービス・ライフサイクルの中心、または開始地点として、組織の達成目標と顧客のニーズを理解すること、また、財務的観点と技術的観点の両面から、サービスマネジメントの方針、指針、プロセスの策定に役立つ基本原則を提供すること。 (2)サービスデザイン (SD) 事業達成目標を認識し、全体の要件を網羅し、優先度を考慮し、全ての利害関係者と必要なコミュニケーションをとり、的確なサービスマネジメントの設計、開発を行うこと。 (3)サービストランジション (ST) リスクを含み、複雑性をもつ、サービスの移行段階において、プログラム管理、プロジェクト管理と明確な協力関係を持ち、移行に関するリスクをコントロールし、事業組織全体を、費用対効果高く、確実に、新しい環境に移行すること。 (4)サービスオペレーション (SO) 　サービスデザインで戦略的に設計されたサービスデザインパッケージを引き継いで移行した、サービストランジションから、運用を引き継ぐことにより、事業全体の活動を、事業の目標にそって、戦略的に、安定的に、支援していくこと。 (5)継続的サービス改善 (CSI) 　より良い戦略、設計、移行、運用を目指す。具体的には、サービス品質を改善し、運用の効率化をすすめ、事業の継続性を維持し、事業全体の目標にそった形で、サービス・ライフサイクルを通して、改善活動を計画、実施すること。各ライフサイクル共通の用語の意味は以下の通りである。「サービス」サービスとは、顧客に特定の価値を提供することである。それによって、顧客は、直接、失敗のリスクとコストを負う必要がなく、それらをサービス・プロバイダに負わせることができ、自らの目標を達成したり、自らの事業に専念することができるので、業務効率がよくなる。従って、サービス・プロバイダは、リスクやコストを適切にコントロールする能力を持った、専門家であるべきである。サービスの価値は、顧客が決める、顧客が定義するという性質があるため、最終的には、その価格でサービスを受けるかどうかは、顧客が決めることになる。また、価値は変化するので、サービス内容は、常に変化させなければならない。「サービスマネジメント」戦略、設計、移行、運用、継続的改善の5つのライフサイクルを通して、一定品質のサービス供給が続く確約

2. 2 をし、顧客に価値をもたらすプロセスの一連の活動をサービスマネジメントという。一連の活動とは、人材や能力などのサービス資産をインプットし、4つの機能（サービスデスク、運用管理、技術管理、アプリケーション管理）を使用して、26個のプロセス（変更管理、ナレッジ管理など）をコントロール、変換し、顧客に成果をアウトプットすることである。その価値、成果とは、求めているパフォーマンスが実現されること、または、実現のための制約がないことなどの有用性と、十分な可用性、キャパシティ、継続性、セキュリティの全てがある状態の保証の二つが存在することである。「プロセス」プロセスは、特定の目的を達成するための一連の定義をした活動のことである。プロセスは、測定するものであり、プロセス・マネージャは、プロセスのコスト、品質を測定したいと考え、プロセス実務者は、期間と生産性の測定をしたいと考えるという違いがある。プロセスの仕組みは、データなどのトリガを受けて、プロセスが一連の活動を行い、その成果をアウトプットとして、顧客、または利害関係者に提供する。その成果のデータが、再び、トリガとなり、プロセス→成果となることを繰り返し、閉ループとなる。これは、パフォーマンス駆動型と呼ばれ、閉ループする度に内容が適切に変化していく。つまり、プロセスは、継続性、反復性、改善性がある。また、プロセスは、特定の結果が必ずあるため、完了した数を数えられる。それに対して、機能は、完了した数を数えられないという性質がある。「機能」機能は、サービス資産（つちかったナレッジ、人材、使用するツール）を使用して、プロセスを実施する。機能は、組織の構成単位であり、あるプロセスの実施に専念する一連の活動を行い、特定の成果を出すことに責任を負っている。つまり、機能は、パフォーマンスを発揮する、専門的な集団でなければならない。機能には、 RACI(Responsible=実行責任者：一名, Accountable=説明責任者, Consulted=相談先, Informed=報告先)と呼ばれる、責任と役割が与えられている。適切なプロセスがあれば、機能の生産性が改善される。第1章　 SOAについて SOA(Service Offering and Agreement)「サービス提案と合意」について、以下の通りまとめた。価値創出と有用性および保証 ITサービスは、その成果を定性化できても、金銭的なものに換算（定量化）するのが困難である。ITサービスの価値創造の定量化を試みるのであれば、顧客はどのように価値を認識するかを、「参照値(顧客自らできていること) + サービス利用による顧客の利益 - サービス利用による損失　=　サービスの経済的価値」、「サービスの経済的価値 – 参照値 =　サービスの差」でみることができる。このサービスの差は、サービスプロバイダが提供できる、（最終的な）有益な「有用性と保証」となる。（ただし、これらは全て、顧客側の認識と好みと顧客側が算出した事業成果がベースになっていることに注意しなければならない。）このサービスの価値を決める有用性とは、パフォーマンスがサポートされているか、制約が排除されているかなどの、目的への適合性（機能性）のことである。保証とは、可用性は十分か、キャパシティは十分か、継続性は十分か、セキュリティは十分かという、使用への適合性（管理性）のことである。アプリケーションの開発など、有用性を確認する設計のフェーズは、単独で実行されてはならず、保証を確認する運用フェーズが関与すると価値が高くなる。設計フェーズが終了してから、運用フェーズにはいると、手戻りの追加コストが発生する場合があり、価値が低くなってしまう。また、有用性と保証の高低は、バランスがとれると複合効果が生まれ、価値を創出する。サービス・カタログ・マネージャとサービスレベル・マネージャの立場 1 組織の駆け引きや自己利益のためではなく、達成目標の全体的な実現を目指す戦略をつくる。 2 チームカルチャの養成、メンタリング、コーチングをする。 3 投資が組織の意図する発展と成長に見合うようにする。 4 事業へのインパクトが最大となる領域を考え、投資の優先度付けをする。 5 分析結果に基づき、意思決定する。 6 戦略、方針、規則、契約を、評価、方向付け、モニタリングする。 7 妥当性が確認された事業にのみ、投資、支出することにより、コスト削減し、ROIを最大化する。

3. 3 8 主要プロジェクトやサービス改善に対する投資レベルを引き上げる。 9 上級マネジメントから指示を受け、報告をする。 10 顧客のニーズを知り、支援する。 11 他のマネージャを巻き込み、支援する。サービスデザインが抱えるリスクや課題課題：　マネージャは、次の課題を解決するよう、努めなければならない。設計されていないサービスやプロセスは、無秩序に発展していくこと。適切なコントロールなしに発展する場合、全体的なビジョン、および、ビジネス・ニーズを明確に理解することなく、発生した環境条件に、リアクティブに反応するだけのものになる。サービスデザインに対する、反復的、および斬新的なアプローチが必要である。リスク：　サービスデザインがない場合、極めてコスト高になり、費用対効果がうすい。また、サービスオペレーション段階等で、障害が発生しやすくなる。リソースは、無駄に消費され、ビジネス・ニーズに整合されなくなる。どのような改善計画をもっても、達成できたはずの事業目標は達成されない。「マネージャの立場」に則った行動 a. マネージャの立場に則った行動 1 事業目標、事業利益、投資の優先順位を常に念頭において、行動する。 2 上（上級マネジメント）、横（顧客と他のITマネージャ）、下（部下、プロセス、技術、ツール）のコントロールに同じくらいの比重を置く。 3 サービスマネジメントとは何かを第一に考える。 b. そうでない行動 1 自己利益や保身のために、社内政治活動にはげむ。 2 部下の仕事を細かく監視したり、手伝ったりしてしまい、部下のモチベーションを下げる。 3 事業目標を考えず、目先のプロジェクトをこなす。ポートフォリオ管理ポートフォリオついてポートフォリオとは、投資ポートフォリオと同じで、顧客のリスクと収益の特性に基づいて調整されるべきで、受容可能なリスク・レベルで利益を最大化する。従って、条件が変われば、変更が反映され、ポートフォリオは、更新されるべきである。 ITサービスのポートフォリオには、サービス・ポートフォリオ、アプリケーション・ポートフォリオ、顧客ポートフォリオ、顧客合意ポートフォリオ、プロジェクト・ポートフォリオがあるが、ポートフォリオ管理の管轄内である、サービス・ポートフォリオについてのみ、以下に説明する。これは、事業上の価値の観点から、プロバイダが提供する、稼働中、または展開許可済みサービス(=サービス・カタログ)、準備中または開発中のサービス（=パイプライン）、廃止済みのサービスを説明して、文書化したものである。これは、様々なプロバイダの競争力を比較する手段となる。作成の目的は、ITへの投資と事業成果を実現する能力とのバランスを取るために、適切なサービスを準備するようにすることである。ポートフォリオの事業に与える価値は、事業がITサービス投資について、健全な意思決定ができるようになることである。サービス・ポートフォリオが明確にする戦略的な問い戦略的な問いとは、次の事項である。「サービス・プロバイダの長期的な最終目標は何か？それを達成するには、どのようなサービスが必要か？組織がそれらのサービスを実現するには、どのような能力とリソース（リソース資産）が必要か？どのようにして、目標を達成するのか？」これらの質問に満足いくように答えられるには、上級リーダと、上級アーキテクトなどの対象分野の専門家の参画が必要になる。このグループは、サービス・アーキテクチャ委員会（SAB）と呼ばれ、前述の戦略的な問いに明確に答えるのを支援し、また、各サービスの分析を行なうことにより、サービス・ポートフォリオが明確に、戦略的に、事業に価値をもたらすことになる。サービス・ポートフォリオ管理プロセスの活動 1. 活動の開始：　戦略管理、事業関係管理、継続的サービス改善、その他のサービス・プロセス・マネジメント・プロセスがトリガとなる。ここでは例として、継続的サービス改善を扱う。CSIは、サービス・ポートフォリオ管理に対して、パフォーマンスやサービスレベル達成度を改善する機会、新しい機会や現行のサービ

4. 4 ス・ポートフォリオ内にあるギャップ、全体的な改善の機会の3つをインプットとする。 2. 定義する: 求められる事業成果、機会、有用性と保証の要件、およびサービスそのものを定義するとともに、これらを達成するための予測される投資を定義することである。カタログ管理カタログ管理の目標事業顧客に対して、どのようなサービスを提供しているのか、どのようなサービスが承認され、今後、提供を受けられるのか、どのサービスが無くなったのか、どのサービスが足りないのかを明確に示す事によって、顧客がサービスを受けやすくなったり、今後、受けたいサービスがわかったりして、事業が発展する。また、顧客が、サービスについて適切な価格で提供されているかについて検討できるようになる。そのカタログは常に最新の状態であることが前提となる。サービス・カタログの内容についてサービス・カタログには、2種類あり、両方ともサービス・ポートフォリオの中に含まれる。 a)技術サービス・カタログであり、事業側には公開されない、サポートスタッフのためのカタログ内容は、サービス、ハードウェア、ソフトウェア、ネットワーク、アプリケーション、データ、サプライヤなどである。現在提供されているサービス、承認済みだがまだ提供されていないサービスの2種類が記載される。 b)事業サービス・カタログ顧客に供給することを約束しているあらゆるサービス情報を一元的に管理し、許可された全ての関係者にその情報を供給する。内容は、サービス、サポートされている製品方針、順序づけや要求手順、サポート条件、エントリ・ポイントとエスカレーション、価格設定と課金方法である。ユーザグループによって、違うビューを使用して、異なるカタログを見せることも可能である。サービスレベル管理サービスレベル管理の目標 SLMの目的は、現在のサービス、および準備中のサービスが、合意された達成可能な目標値を満たすようにすることである。それを達成するためには、次の目標を掲げる。ITサービスレベルを定義、文書化、合意、モニタリング、測定、報告、レビューし、適宜、改善措置をとる。事業関係管理と協力して、事業および顧客との関係を円滑に維持し、適宜、改善していく。ITサービスを測定可能な目標値で、設定できるようにする。サービス品質に対しての顧客満足度をモニタリングし、適宜、改善する。合意されたレベルで品質が維持されていたとしても、常に対費用効果が高く、常に継続的改善の対象となるようにする。 SLAおよびOLA SLA：　ITサービス・プロバイダと事業顧客の間で交わされる合意文書であり、各サービスの目標値と、両者の責任を定義している。これは、違反したら賠償金を払うためのものではなく、両者の合意に重点がおかれている。SLAは、サービスが提供するべき有用性とその保証を定義する。SLAは、サービスレベル管理(SLM)によって、立案計画、調整、起草、合意、モニタリング、報告される。 OLA: ITサービス・プロバイダと、それを支援する同じ組織の別部門（購買、施設管理など）との間で交わされる合意文書であり、OLAは、支援サービス活動がSLA違反を引き起こさないように、SLA内の目標値を支える目標値を定める。 SLAの種類 a) サービスベースのSLA：　メール・サービスなどの全従業員が使用する単一のサービスのSLAを規定し、そのサービスのすべてのユーザを対象とする。しかしながら、メール・サービスといっても、従業員によっては、自宅から使用したり、別拠点からVPN接続で使用していたり、本社の社内LANからアクセスしたりなど、条件が異なるのに、同じSLAでよいかという問題と、どの使用方法による代表者が合意書への署名者となるかという問題がある。サービスレベルの有効性を高めるために、複数のサービス階級を使用することも検討される。 b) 顧客ベースのSLA：　財務システム、給与システム、請求システム、メールシステムなど、1つの部門で使用されるすべてのサービスに対して、単一のSLAを規定する。顧客側は、1つの文書で要件が満たされるため、好まれることが多い。署名者は一名ですむため、明快である。 c) マルチレベルSLA：　例えば次のような階層構造となることがあるがこの限りではない。特定サービスレベルのSLA、顧客レベルのSLAまたは事業部門レベルのSLA 、企業レベルのSLAの組み合わせである。詳細は、上記 a)、b)と同様である。階層の複合SLAとすることによ

5. 5 り、SLAを扱いやすいサイズに維持できるようになり、不必要な重複が回避され、頻繁な更新の必要性が少なくなるという利点がある。リスクとしては、サービス・カタログとCMS内での、必要な関連を維持するために、さらなる労力を要することである。サービスレベル管理の活動について主な活動は次の通りである。1) SLRにある新規または変更されるサービス要件の判断、交渉、文書化、合意、およびサービス・ライフサイクルを通した、これらの要件の管理、およびレビューと運用中のサービスを SLAに落とし込むこと。2)サービス・パフォーマンスの SLA達成度のモニタリングと測定。3) サービス・レポートの作成、4) サービス・レビューを行い、CSI管理表に、改善の機会を含め、SIPを適切に管理する。5) 事業関係管理との協力による、顧客満足度の測定と、結果に応じた改善。6) SLA,サービス適用範囲、OLAのレビューと改訂、7) 事業関係管理プロセスとの協力による、苦情と賛辞の記録と管理など。サービスレベル管理の活動の実態ステップ1 - 可用性管理が、現在のBlackberryサーバの可用性とキャパシティを測定し、ベースラインとした。その結果に基づいて作成されたSLAを、事業顧客管理を含めて、事業顧客と話し合い、サービスレベル管理が、 Blackberryメール・サービスに対して、サービスベースのSLAを、可用性24時間　365日稼働、障害時や保守によるダウンタイム一回に2時間以内、ダウンは、発生しても、4ヶ月に一回以下、Blackberryでのメール送受信開始までの時間(応答性)が3秒以内で、それを下回る期間が、1時間以内であることなど、エンドツーエンドでのパフォーマンスについて取り決め、顧客と合意した（ 99.8%など、顧客がわからないような表現を使わない）。また、そのSLAを達成するために、そのサービスを支援する、NTTドコモや、 RIM社などのサプライヤ 1 とも別途、SLAに合意し、法的拘束力のある外部委託契約にサインした。社内の調達部門とは、Blackberry入手 1 Blackberry端末と、Blackberry Enterprise Serverを開発している、カナダのリサーチ・イン・モーション社の略称。2014年現在は、社名をブランド名と同じ、 Blackberryとしている。2013年2月に、日本市場からの撤退を発表した。をユーザがリクエストしてから、14日以内にITに届けるというOLAに合意した。ステップ2 – サービス・パフォーマンスのSLA達成度のモニタリングと測定。ステップ3 – RAGチャートを含んだサービス・レポートの作成。ステップ4 - サービス・レビューを実施し、セキュリティの脆弱性が可用性に与えるインパクトを考慮して、Blackberry OSのバージョンアップの検討などをSIPに追加した。ステップ5 – ケース・クローズがトリガーとなる、インシデント管理ツールの自動応答サーベイ送信（10段階評価で、満足度をマークするようになっており、忌憚のない意見を記載できる、自由形式の欄もある。）を通じて、 Blackberry に関するインシデントのユーザ満足度を調査した。　需要管理需要管理とは 12月には、年賀カードがよく売れる、経理部スタッフは、毎月月末は非常に忙しいなどという、事業顧客の事業活動パターンやユーザ・プロファイルを把握、予測、分析し、サービス資産のキャパシティやパフォーマンスが過不足なく提供されることを、キャパシティ管理と共にコントロールしていくプロセスである。需要管理に固有なプロセスとしては、事業の繁忙期を拡散させて、特定のサーバへのアクセス量をコントロールするような、奨励、罰則などの戦略によって、需要に影響を与えることと、事業目標数値達成とIT投資の両方のバランスをとる方策をさぐることである。需要管理と一番密接な関係にあるプロセスキャパシティ管理プロセスである。どちらも、事業成果実現とIT投資の最適化を目標とするが、次の点で異なる。需要管理は、ややビジネスとユーザ寄りのプロセスであり、事業顧客が、自らの顧客に対し、格差課金をもうけ、繁忙期を拡散するなどして、製品需要の調整を図るのを受けて、ITサービスの需要を予測して、戦略を立てる。一方、キャパシティ管理は、ITサービスと技術寄りのプロセスであり、需要管理から受けた需要情報により、サービス資産のキャパシティやパフォーマンスが過不足のないように管理する。このように、キャパシティ管理の仕事は、需要管理から引き継がれていること、ま

6. 6 た、需要があるから、キャパシティが必要になることからも、これらのプロセスは密接な関係にあると言える。コアサービスと支援サービスコアサービスとは、例えば、メールの送受信ができるなど、顧客にとっての基本的なサービスである。それに対して、支援サービスとは、顧客の要望に合わせて、ドミノサーバであったり、Exchangeサーバであったり、 Office 365であったりと選べて、更に、メールの送受信が、24時間365日可能であることを保証するなど、顧客にとっての付加価値を提供する、魅力サービスである。これらの組み合わせは、サービス・パッケージとして顧客に提示され、サービス・プロバイダは、これをサービス・ポートフォリオ管理に組み入れ、購入/導入を検討する。同時に、このコアサービスと支援サービスの組み合わせで、顧客の事業活動パターンとユーザ・プロファイルに適合するか、需要管理にて検討することになる。需要をコントロールする方法需要管理が、事業活動パターンとユーザ・プロファイルを分析することによって、どのユーザが、どのサービスを、どの時期（どの時間帯）に、どのくらい必要とするのかを事前に知る。それによって、ユーザが、期限までに入力しないと経費の振込が来月に繰り越されるなどの罰則をもうけて経費精算システムの使用を平準化させてコントロールすることがある。また、キャパシティ管理が、事業環境の変化を把握し、新しい技術やサービス要件をサービス・ポートフォリオに反映し、リソース予測を正確にすることで、需要に対応することも、需要をコントロールする方法といえる。提供しているサービスの「事業活動パターン」 Altirisツール・サービスの事業活動パターン Altirisは、ITILフレームワークを強力にサポートする ITSMツールである。使用対象者は、事業顧客の全ユユーザ、5000名であり、ITスタッフのみではなく、入退社の管理上、人事部も利用頻度が高い。インシデント管理、問題管理、要求実現、アクセス管理その他に使用される。要求実現は、イントラネットから、買い物かご方式で、必要なサービスをサービス・カタログから、ユーザ自ら選択でき、自動でチケット起票される。インシデントについては、ユーザがチケットを起票する。サービスデスクは、フォロー・ザ・サンなので、 Altirisは、24時間月〜金、使用されており、トランザクションの多い時間帯は、24h、常に、である。時期的には、毎月月末と、四半期の終わりと、会計年度末である。それぞれのタイムゾーンごと(APAC, EMEA, USの日中)に、ユーザが1500人ずつなので負荷分散措置はとっていないが、今後、APAC, EMEA, USの従業員数のバランスが、崩れることがないよう、需要管理し、格差課金が設けられなければ、キャパシティ管理が調整する必要がある。サプライヤ管理サプライヤとはサプライヤには、上位から、戦略的サプライヤ、戦術的サプライヤ、運用上のサプライヤ、コモディティ・サプライヤの4つに分類される。サプライヤというと、サービス・プロバイダに従属的に仕事をするというイメージがある。戦略的サプライヤは、パートナーとして、サービス・プロバイダやその事業顧客と対等に、そして長期的にコミットメントを交わし、戦略の機密情報を共有し、連帯責任を負い、共有のリスク、および報酬を得ることがあるので、サービス・プロバイダの上級マネジメントのレベルで管理される。例)アジア規模で、統一されたネットワーク構築サービスと運用管理を任せるなど。戦術的サプライヤは、商業活動および事業とのやり取りが関与する関係にあり、進行中の改善プログラムを含む定期的な連絡とパフォーマンス・レビューを伴い、中級マネジメントによって管理される。例）サーバのハードウェア故障の解決を提供する保守組織）。運用上のサプライヤは、運用上の製品または、サービスを提供し、頻繁ではない定期的な連絡とパフォーマンス・レビューを伴い、下級マネジメントによって管理される。例）ホスティング・サービスのプロバイダなど。コモディティ・サプライヤは、比較的用意に代替ソーシングされる、価値の低い、用意に入手できる製品とサービスを提供する。例）プリンタ・カートリッジの提供。 1つの事柄に対して、複数のサプライヤを使用すると、管理が煩雑になるが、リスクが分散される。単一のサプライヤを使用すると、管理は楽になるが、その分、依存していることによるリスク、コストが大きくなる。特に、サービスをサプライヤがカスタマイズしていると、代替サプライヤに移行することは更に困難になることに注意する。

7. 7 サプライヤ管理の達成目標事業顧客または、サービス・プロバイダが投資した価値に見合う成果を取得すること、契約内容が、事業顧客のニーズに整合するように管理すること、サービスレベル管理プロセスと連携して、SLAとSLAの合意済み目標値を決めること、サプライヤとの関係を完全に管理すること、サプライヤのパフォーマンスをレビューし、管理すること、契約について、サプライヤと交渉、および合意し、そのライフサイクルを通して管理すること、サプライヤの方針と、それを支えるサプライヤおよび契約管理情報システム(SCMIS)を維持管理することを達成目標とする。サプライヤ契約データベースとはサプライヤおよび契約管理情報システム(SCMIS)は、サービス・プロバイダの、すべてのサプライヤに対する方針が、一貫性と有効性を持つようにする目的で作成される。SCMISには、各サプライヤが提供するサービス、または製品の種類の詳細、および他の関連するCI情報、契約の内容を記録し、CMSまたはSKMSに統合されなければならない。これは、サービス・ポートフォリオとサービス・カタログも形成する。SCMISの中の以下の情報は、サプライヤ管理の手順と活動に、参考情報一式を提供する。①新しいサプライヤ、および契約の要件の定義、②新しいサプライヤ、および契約の評価と設定、③サプライヤのカテゴリ化とSCMISの維持管理、 ④新しいサプライヤの確立、⑤サプライヤとそのパフォーマンス、および関連する契約の管理、⑥契約の更新または終了。サプライヤ管理における課題、重要成功要因、リスク課題：サプライヤ管理プロセス・マネージャは、次のことを課題として、解決に努めなければならない。常に変化するビジネス・ニーズとITニーズによる変更管理。不十分な目標値、パフォーマンスの測定定義をもたない契約により業務を行なうこと。組織内に十分な専門知識がないこと。改善の可能性がないにもかかわらず、早期終了に対する懲罰的な違約金のある、長期契約よる束縛（＝コスト増）。料金に関する争議。日常的な火消し作業に追われ、プロアクティブなアプローチがなされないこと。戦略的観点を失い、運用上の課題にのみ焦点を当てることにより、目標を達成できていない、課題を解決できていないこと。 CSF: サプライヤが、十分なパフォーマンスを発揮しており、ビジネス・ニーズおよび事業目標値と整合する支援サービスをもっており、十分な可用性を提供しており、プロバイダが、サプライヤ契約について明確なオーナシップがとっていること。リスク：　事業と上級マネジメントから、サプライヤ管理のプロセスへのコミットメントが不足していること。事業とITの将来的な方針、計画、戦略に関する情報が不足していること。リソースや予算が不足していること。ビジネス・ニーズ、SLA, SLRの目標値を裏付けない古い契約。サプライヤの引き継ぎがあり、関係、リソース、契約が変更されること。財務管理財務管理を行うメリットまず、財務管理プロセスには、次の3つの業務がある。予算と実際の出費との不一致、収入を監視する。= 会計業務。予算を作成し、管理する。= 予算業務。支払いに対して請求をする。= 課金業務。財務管理を行なうメリットは、規制機関(エンロン事件をきっかけに出来たSOX法、US-GAAPなどの会計作成と報告)の定めに従って、適切なデータに基づいて、法令に遵守し、罰則を回避した、健全な事業の意思決定ができるようになる。また、事業を継続するか撤退するかを、サービスとコストの関係を明らかにする、サービス・ポートフォリオを元にして、財務上の裏付けをもって判断できる。また、財務管理は、需要と供給の関係を考えて、課金システムを立案し、コストを最適化し、妥当な投資を、ITサービスマネジメントに対して行なうことができる。「サービス査定」についてサービス査定は、次の2つのことである。a) 供給価値 – ITサービスを提供するのに必要な、有形無形のものの原価。例）ハードウェア、ソフトウェアライセンス、年間保守料、人件費、設備費、コンプライアンスのコスト。b) サービスの潜在的価値 – ITサービスの提供によって、事業に付加された分の価値であるが、事業顧客が実感する価値なので、実際の値段はない。例） 2 「サービスに対する価値認識（有用性と保証） = 　顧客自身の資産　+ 　サービスの潜在価値」投資利益率（ROI）とは 2

8. 8 ROI(Return On Investment)は、ITサービスから得られた、事業顧客の利益の増加（=投資の正味利益）を、事業顧客が支払ったITサービスへの投資合計で割り、 100%を乗じたものである。この結果は、その企業のIT サービスが、プロフィットセンターと見なされるか、コストセンターと見なされるかにより、財務諸表の収益に追加されるか、コストから控除される。ROIは、ITサービス投資の価値を定量化するための概念であるが、IT サービスの提供には多くの無形の要素が関与しているため、この計算式は、単純化されすぎており、潜在的な利益（顧客ロイヤルティの向上など定性的なもの）を完全には示していない。第2章　PPOについて PPO（Planning, Protection & Operation)「計画立案保護、および最適化」について、以下の通りまとめた。サービスマネジメントとして優れている部分と劣っている部分 (1)優れているサービスマネジメント - 　Altirisツールを使用し、全ての情報が一括管理されている。 - 　役割と機能がITIL通りである。 - 　サービスデスク機能が充実している（スキルと時間）。日本の祝日も含み、月曜日9:00 AM JSTから土曜日8:00AM JST（=金曜日17:00 PST） - インフラサポートは、24時間365 日障害対応可能。 - 情報セキュリティ方針委員会が機能している。 - 2011年の東日本大震災時には、適切なBCPにより、問題がなかった。 - マネジメントの柔軟性とリスク回避のバランスが良い。例えば、米国本社主導型のトップダウンであるが、日本の事業関係管理は、現場のIT部門に権限委譲されており、日本だけは「欧米とも、アジアとも異なる、希有な文化圏」として、日本のボードメンバー全員の強い要請があれば、ごく稀に例外が認められることがある（米国本社マネージャの承認は事前に必要）。劣っているサービスマネジメント - 内部サービス・プロバイダゆえ、障害が起きても、事業顧客は我慢してくれるという意識がなくもない。 - 需要管理プロセスの課金モデルアセスメントがない。 - 米国本社主導型なので、日本人ユーザの顧客満足度が低い。例）a. 英語でのサポート依頼、英語OS、英語アプリの強制的使用、b. 購入申請しても、ルーティングが米国本社まで通る必要があり、承認者の人数が多いので、なかなか購入物が来ない、c. 車社会ではないのに、米国本社指定の重いLaptop PCを使わされている等。ただ、APAC諸国では、そのような不満のサーベイ結果はないので、日本人特有と思われる。事実、日本支社の外国人社員、海外勤務経験のある日本人からは不満はない。日本以外に多い、プロセス重視型の人材を育成し、ユーザ側からの歩み寄りを求める（ただし、この部分は、ITILの管轄外）。サービスデザインを適切に実施することのメリットサービスデザインを適切に実施することのメリットは、サービスライフサイクルにおいて、必要となる改善が最小限になることである。この改善は、時の経過とともに、事業の方向性が変わったり、事業とは関係なく、国内のインフラ技術が進化したりするので、必ず必要となるが、スムーズに終わらせるようにしなければならない。この実施については、サービス・トラジション、及びサービス・オペレーションへの影響も考慮して、サービスデインパッケージをしっかり準備しておくべきである。特に、Office 365 や、サイボーズのビジネスクラ 3 ウドなどの大規模クラウドコンピューティング技術を 4 使用する顧客にとっては、大きな投資になるので、導入前に費用対効果を確認できるというメリットがある。また、この適切な実施は、ITガバナンスにもつながる。 3 Office 365のテクニカルサポートは、24時間365日対応可能であり、可用性は99.9%を保証し、満たされていない顧客には、同社規定に基づいた額の返金が行なわれる。(2014年４月27日現在) 4 サイボーズ社が開発した、メールとイントラネット（ファイルサーバ機能あり）サービス。ユーザ数によっ

9. 9 更に優れた取り組みをすることが可能なＰＰＯに含まれるプロセスと、考えられる効果上記事業顧客における、情報セキュリティ管理プロセスは、導入段階において、サービスデザインパッケージ (SDP)に適切に組み込まれ、サービストランジションに渡され、サービス・オペレーションが適切に対応したことにより、AD /Exchangeサーバ/ファイルサーバ移行プロジェクト時に、障害があったものの、ユーザにとって、最小限の被害ですみ、予定通りにプロジェクトが終了した。障害内容：　休日のExchangeサーバ移行時に、ディストリビューションリスト(DL)の一部のデータが失われた。また、ファイルサーバ移行時に、フォルダセキュリティ設定の一部の設定が失われた。 ITの行動: 顧客側の各部門長に、障害情報を速やかに通知し、顧客サービスカタログに記載されているように、手順に従って作業し、ヘルプが必要な場合は、サービスデスクに電話するよう依頼し、速やかに、当プロジェクトの他の作業を続行し、翌朝の業務開始時刻までに、全移行作業を終了させた。顧客の行動：月曜日の朝、出社したDLオーナである部門長が、DL紙リストを元に、DLリストに正しいメンバの追加を行なった。同様に、各部門フォルダ・オーナである部門長が、アクセス権紙リストを元に、部門フォルダ配下にある、全フォルダに、正しいメンバのアクセス権の追加を行った。結果、全ユーザが、 9:15AMには、CIAの保たれた状態で、グループメールを受領する事ができ、また、アクセスすべきフォルダにアクセスすることができ、通常業務に戻れた。サービスカタログへの記載: a) DLは、部門長から依頼により、ITが作成する。ただし、DLへのメンバの追加、削除は、部門長自身が行い、管理すること。b) ファイルサーバの部門フォルダは、ITしか作成してはいけない。ただし、部門フォルダ配下のフォルダの作成、アクセス権付与については、部門長が作成、更新、管理する。注意: ファイルサーバ管理者は、全てのフォルダに対して、フルアクセス権を持つが、サポート目的以外では、アクセスしない。適切なSDPがなかった場合：　誰がアクセス権を元に戻す責任があるのかわからない、アクセス権の付与手順がわからない、元のアクセス権がどうだったかわからない等のことから、ITとユーザ側でもめるだけで、業務が滞り、ITサービス業務も滞り、ビジネスチャンスを失いかねなかった。改善点: 障害時刻から、月曜日の朝までにDL宛に送付されたメールは、届かなかった。休日に、VPN経由で、ファイルサーバを使用しようとしていたユーザは、月曜日の朝まで、目的のフォルダにアクセスできなかった。休日でも、ECABを招集して、各部門長の緊急対応を義務づけることに合意させたほうがいいかもしれない。IT がこれらのアクセスコントロールをすることは、リソースの都合上と機密文書セキュリティの観点から、関与しないことになっているが、部門長が何らかの事情で対応できなかった場合は、ITが、各部門長のバックアップ要員になるべきかもしれない。IT側で、ベースライン設定し、切り戻し方法を取るべきだったかもしれない。これらの点は、情報セキュリティ管理マネージャがCSI管理表に記載し、可用性管理マネージャと共に改善にあたれば、更に優れたPPOを実現し、可用性を高める効果がある。下記4つのプロセス・マネージャは、それぞれのプロセスが密接に関連しているため、相互に連携し、IT財務サービス管理の理解を得て、事業顧客からの適切な投資を正当化する材料を用意する責任がある。下記4つのプロセス・マネージャに共通する事項は、 a) プロセスの運用管理に責任を持ち、役割に人材を任命し、リソースを管理すること、c) 必要な投資、管理手順については、そのプロセス・オーナとともに計画立案化すること、d) パフォーマンスをモニタリングし、プロセス・オーナに報告すること、e) CSI管理表を作成、更新すること、f) 合意されたSLAを遵守するよう監視すること、g) 必要なCABミーティングに参加すること、h) 前述したこと全てを最新の状態の文書にすることである。 CIOへの説明責任、KPIの分析については、そのプロセス・オーナの責任なので責任範疇外とする。ただし、マネージャが、そのプロセス・オーナを兼任する場合はこの限りではない。また、プロセス・マネージャは拠点ごとなどに複数設置することがあるので、お互いに連携を取り合うこと。それぞれのマネージャ特有の責任については、下記の通りである。 (1)可用性マネージャ　- 内部サプライヤ、外部サプライヤが提供する、コンポーネントの信頼性、保守性、サー

10. 10 ビス性の要件の特定に責任を負う。関連するインシデント、問題管理を支援する。リスク・アセスメントとリスク管理を行なう。 (2)ITSCMマネージャ – ビジネス・インパクト分析、リスク・アセスメントとリスク管理を行なう。災害が発生した場合、サービス継続性計画を発動して、復旧を指揮する。そのテスト、事後レビュー、是正措置を指揮する。復旧サービス・プロバイダとの契約管理をする。 SLAは、顧客というよりは、事業と締結する。 (3)キャパシティ・マネージャ - キャパシティと需要の関係を調整することについて責任を負う。過去、現在、将来のコンポーネントの使用率、最大キャパシティ、パフォーマンスのしきい値、チューニング方法を分析する。関連するインシデント、問題管理を支援する。 (4)セキュリティ・マネージャ – ITSCMマネージャがビジネス・インパクト分析をするのを支援する。関連するインシデント、問題管理を支援する。セキュリティ・リスク・アセスメントとリスク管理を遂行する。自社のセキュリティ方針について、顧客とユーザに普及させる。可用性に関する「課題、CSF、リスク」 (1)課題：　サービス・チケッティング・システムの Altiris が、業務時間内に、一週間に2回、5時間程度ダウ 5 ンするか、応答速度が極端に遅くなる。SLAでは、月〜金（日本の祝日を除く）　9:30 - 17:30 の間、99.99%の可用性で稼働していること、また、ダウンした場合は Severity2とされ、インシデントチケットが報告されてから、3時間以内に復旧することとなっており、新規導入してから一年近く、SLA違反状態である。Altirisサーバは米国にあり、技術管理、アプリケーション管理も米国にある。 [現状] 可用性(%) = 合意済みサービス時間(時間) – 停止時間x 100 = ( 480h /1920h ) x 100 = 25% SLAを下げる方向で、事業顧客と合意をとる必要があるが、このアプリケーションは、IT内でのみで使用される 5 米国サンディエゴ本社のAltiris社が開発した、ITSMソフトウェア。インシデント管理、問題管理、FAQの管理が出来る。Altirisと違い、ユーザがチケットを起起票するインターフェイスはないが、イントラネットと連動させ、ユーザからの要求実現リクエスト入力を自動起票させることが可能。ので、顧客にとってはVBFでなく、顧客には間接的な影響しかないことから、話し合いが先延ばしにされている。しかしながら、実際は、ユーザからインシデントの報告を受けても、サービスデスクがチケットを起票できない、技術管理が更新した、既知のエラーのワークアラウンドを、サービスデスクが閲覧出来ないことから、ユーザに対するサービス対応が大幅遅れており、事業顧客のビジネスにインパクトが大きい。また、サービス・プロバイダの仕事効率は著しく低下しているが、インパクトが測定されていない。このように、事業顧客に、 Altirisの高可用性の必要性が認識されていないことにより、適切な投資、改善活動が行なわれない。AMISに情報は統合されているが、AMISが、Altirisの中にあるので、それを活用することができない。 (2)CSF　 - SLA上で、Altirisの可用性は、98.12%、信頼性 (MTBSI)は、160時間（1年に12回のダウン）、保守性 (MTRS)は、3時間（1年に12回のダウンで、総停止時間は36時間）とし、可用性と信頼性が管理されている。 - Altirisの利用に対するビジネス・ニーズの充足。 - 最適なコストで提供されている。 (3)リスク - Altirisは、IT内でしか使用しないITSMツールではあるが、事業顧客の事業継続性に欠く事ができないものであり、ITトラブルが発生した個々のユーザ、全体のトラブルの発生時には、Altirisの可用性が低いことによって、間接的に、事業顧客の全ユーザ、及び、直接的に、サービス・プロバイダの全ユーザが影響を受けていることを、上級マネージャが、経営層に説明できていないこと。 - 上記の理由により、このシステムの可用性プロセスへのリソースと予算が不足していること。 - 7つのグループ会社に個別に報告しなければならないことから、報告プロセスに労力を要すること。　　キャパシティ管理キャパシティ管理の「目標」キャパシティとパフォーマンスに関連する全てのサービスが、事業顧客と合意されたレベルで達成されていることを目標とする。キャパシティへの期待値は常に変化していき、新しい技術も出てくるので、定期的に計測

11. 11 し、新技術には、常に敏感になり、将来のニーズを予測し、適切な予算投資をしていくよう、事業顧客の理解を求めていくことが大事である。サービスデスク機能などの人的リソース、人員配置とスキルレベル、加えて、ネットワーク帯域幅、CPUの性能などのコンポーネントレベルのリソースも、キャパシティ管理の範疇である。高い費用対効果をもって、最適なスケジュールで管理されなければならない。キャパシティ管理の3つのレベル 3つのレベルとは、以下の3つのサブプロセスがあり、これら3つに共通していることは、現在と将来の顧客事業の需要を第一と考えることである。1つ目の事業キャパシティ管理(BCM) は、長期的な将来の事業目的を正確に把握することにより、キャパシティを分析、計画していく。2つ目のサービスキャパシティ管理(SCM) は、ITサービスが、時期や時間や近い事業計画の更新によるトランザクションの効果を分析し、リソースをどのように活用するかを予測していくことである。3つ目のコンポーネントキャパシティ管理(CCM)は、データセンターの空調システム、SECOM入室管理システム、CPU などひとつひとつのコンポーネントのパフォーマンスとキャパシティを予測し、管理する。この3つのサブプロセスは、1→2→3の順で階層となっており、3に不具合があると、2に悪影響があり、それが、1の見直しに繋がるというように、階層的に関連している。キャパシティ管理の課題、重要成功要因、リスク課題：取り扱う情報が膨大なため、適切なしきい値をもうけ、警報とアラートがあがるようにするなど、ツールを使用して、なるべく自動化を計り効率化する必要がある。特に、自身が外部サービス・プロバイダである場合、事業顧客の事業計画を知ることが困難な場合があるが、情報を収集するよう、上級マネジメントに働きかける必要がある。重要成功要因：事業計画に添ったニーズを理解し、キャパシティ管理計画を、費用対効果よく、タイムリーに導入すること。SLA達成を失敗させる古い技術を取り除き、新しい技術を検討するなど、広い技術的ナレッジを持つこと。パフォーマンスが低いことに起因するインシデントを減少させること。リスク：事業顧客や上級マネジメントからの、適切な量のヒト、モノ、カネ、情報が不足していること、事業の将来計画情報がわからないこと、ツールやコンピュータ・システムを利用せず、手作業に頼ることにより、正確で迅速な情報提供ができないこと、ビジネスの観点からわかるようなレポートを作成できないこと。サービス提供インフラと対象としているビジネスにける「事業活動パターン」との関連ユーザの職務により、繁忙期や使用目的が異なるため、キャパシティ管理の重要度は、下表のようにユーザ・プロファイルによって異なる。例えば、社内LANのキャパシティは、下表の通り、特に、この事業顧客のプロダクトを支える技術部門において重要なインフラとなる。この事業顧客のVBFは、ソフトウェア開発環境であり、その重要なサービスは社内LANのパフォーマンスである。しかしながら、その他のユーザにとっての社内 LANのキャパシティ要求は、技術部門よりは高くはない。この事業顧客に特有な、キャパシティ管理と事業活動パターンの関係性は、下表の通りである。ユーザ・プロファイル該当する事業活動パターン（ PBA）キャパシティ管理上級役員 (U P1 ) Blackberryで、常にメールの送受信が可能なことが顧客との良好な関係に欠かせない。全てのアプリケーションに対して、社内 LANの応答時間 5秒以内, VPN接場合は、10秒以移動の多い法人営業 (U P2 ) 顧客との高い接触度。顧客に即応できる必要性。残業が多く、夕方〜深夜までネットワークが稼働していることを期待。電車での移動が多いので、処理能力は落ちても、軽量のPCを必要としている。PCが、常にVPN接続できること、Blackberryで、常にメールの送受信が可能なことが外部顧客への早いレスポンスに欠かせない。全てのアプリケーションに対して、社内 LANの応答時間 3秒以内, VPN接場合は、5秒以内ファイルサーバの使用領一ヶ月 100MB増える。

12. 12 バック・オフィス・スタッフ (U P3 ) 外出がほとんどない。安定した処理性のあるPCが必要だが、重量は気にならない。業務時間中は高い生産性を必要とするが残業はしないので、夕方以降や休日もネットワークが稼働していることまでは期待しない。全てのアプリケーションに対して、社内 LANの応答時間 5秒以内, ファイサーバの使用領一ヶ月 100MB増える。移動の少ない技術スタッフ (U P4 ) オフィスに常駐しており、外出がほとんどない。ソフトウェア開発業なので、大量のデータを頻繁にダウンロードするため、社内ネットワークの信頼性とパフォーマンス（応答時間）への期待値が高い。全てのアプリケーションに対して、社内 LANの応答時間 2秒以内, ファイサーバの使用領一ヶ月 5GB増える。(S 財務管理システム (U P5 ) 締め日前の1週間は、応答が悪くなる。安定したトランザクションを実現するため、ネットワークの速度はあまり気にしないが、ネットワークの高可用性が必須。社内LANの応答時間 5秒以内, VPN接場合は、10秒以内。(SLA) 業務支援プロセス　 - ビジネス・プロセス。ユーザ自身でインシデントを起票、進捗管理するシステム。サービスデスク機能がフォロー・ザ・サンなので、24時間365日、IT、ユーザともに使用。ITは、AltirisをPC ビルドにも使用している。また、人事部と各部門長は、New Hireリクエストに、Altirisを使用社内LANの応答時間 2秒以内, VPN接場合は、5秒以内。(SLA) Alt iri s (U P6 ) しているため、多くの部署で共有されている。可用性管理 1．可用性管理の「目標」必要とされたときに、全てのITサービスが使用でき（信頼性、保守性、サービス性に問題がないか）、パフォーマンスよく（キャパシティに問題がないか）、セキュリティが保たれた状態（安全性に問題がないか）であることを目標とする。しかしながら、事業顧客が、求めていない可用性レベルをサービス・プロバイダが設定し、事業顧客からみて、高すぎる投資が行なわれてはならず、事業顧客と上級マネージャの合意に基づく、適切な可用性目標値を持ち、適正価格の投資が行なわれなければならない。 2．「可用性の2つのレベル」サービス可用性と、コンポーネント可用性の2つのレベルに分類される。ユーザ側からみたときに、使用できるか否か（エンドツーエンドという）の観点から、サービス提供状態にあるかどうかをサービス可用性という。ネットワーク、無停電電源装置(UPS)、データセンターの空調、PCなど、ひとつひとつのコンポーネントが停止しているか否かは、コンポーネント可用性といわれ、サービス・プロバイダ側からみたときに、必要なものが使用できるか否かである。コンポーネントのどれかが停止していれば、サービス可用性に影響がでる可能性がある。従って、この2つは連動性があり、サービス可用性が上層で、コンポーネント可用性が下層の2レイヤーとなる。 3．可用性管理の課題、重要成功要因、リスク課題：　可用性が、顧客の事業、顧客、上級マネジメントの期待に添う数値であること、変化する可用性の期待値を管理していき、必要な予算を正当化することが課題である。マイクロソフト社がOffice 365 のサービスの可 6 6 Office 365のテクニカルサポートは、24時間365日対応可能であり、可用性は99.9%を保証し、満たされていない顧客には、同社規定に基づいた額の返金が行なわれる。http://en.wikipedia.org/wiki/Microsoft_Office_365

13. 13 用性を、99.9%と設定しており、満たさない場合は返金するとうたっていることの影響もあり、当たり前のように、高可用性が求められることが多い。しかしながら、極端な高可用性は不必要な高コストを求めることがあるので、費用対効果が得られない場合があることに注意する必要がある。もう1つの課題として、様々な技術からの情報が、様々なツールによって異なる形式で管理されている場合、ひとつのサービスにみえるものの可用性を管理することは極めて困難であることが挙げられる。例えば、メールの送受信の可用性は、サーバ・ハードウェアの可用性、ISPの可用性、社内ネットワークの可用性、　MS Exchange Serverアプリケーションの可用性、PCの可用性、PCにインストールされたOutlookの可用性、セキュリティの可用性の全てが関係しており、それらは通常、別々の機能により管理されている。一貫した方法で分析できるよう、AMISに情報を統合するべきである。重要成功要因：　エンドツーエンドの可用性が改善されたり、非可用性が削減されたり、MTRSが短縮されたりなどの結果を導くように、可用性が信頼性と共に適切に管理されていること。顧客満足度が高い、VBFの可用性高いなどの結果を導くなど、ビジネス・ニーズを満たしていること。非可用性により発生したコストを削減したり、タイムリーにシステム・レビューが完了するのを実現するような、適切に文書化されたSLAが存在することが、可用性管理のCSFである。リスク：　事業顧客、上級マネジメントからの理解が得られず、適正な予算を確保できていないことが、可用性管理の失敗に繋がる可能性がある。多数のコンポーネントからの膨大な情報が、整理されていない状態で拡散していると、報告プロセスに労力がかかること。エンドツーエンドの可用性や、事業側からみたニーズを軽視して、技術のみに焦点があたりやすいこと。 1．インフラの可用性の指標は、どのように決めたらいいか決め方：　可用性管理プロセス・マネージャが、現在 Blackberryサーバの可用性を測定し、プロセス・オーナに報告し、プロセス・オーナがCIOに説明して、CIOが経営層とのミーティングを行い、事業顧客からの要望、 ITスタッフのリソース、コンポーネント障害時のサプライヤのサービス性をふまえて、SLAを、可用性90.00 % 、24時間　365日稼働、障害や保守によるダウンタイム 2時間以内と決定した。改善点：　Blackberryサーバの可用性を決め、 Blackberryを経由してのメールの送受信の可用性については、Exchangeメールサーバ、Blackberry端末の故障、日本であれば、NTTドコモの基地局の不具合、社内ネットワークの不具合など様々なサービスが複雑に影響しあうが、この点を、事業顧客が理解していない場合、 Blackberryが長い時間使えないとしても、Blackberry サーバ自体は100%正常に稼働しており、Blackberryの可用性は、90.00%というSLAを満たしていることもあるので、「Blackberryを使用してのメールの送受信」の可用性について、SLAを取り決めた方が、事業顧客にはわかりやすく、プロアクティブな処置に対して、適切な投資が行なわれるかもしれない。これらの点について、可用性管理マネージャは、CSI管理表に記載し、キャパシティ管理マネージャ、サプライヤ管理マネージャ、IT サービス財務管理マネージャとともに、改善をしていかなければならない。 ITサービス継続性管理 1．ITサービス継続性管理の「目標」経営層の責任範囲である事業継続性管理プロセス全体を支援すること、また、復旧オプションの選択、導入とリスク軽減手段の策定を目標とする。これは、コンポーネントの障害から起こる可用性の問題を取り扱う、可用性管理プロセスに似ているが、それとは影響規模と責任範囲が異なり、大地震、大火災、刑事事件、情報漏洩などが起きたときに、SLAで合意されたレベルで、事業を再開、継続できることを目標としている。そのため、全ての継続性計画が事業に及ぼすインパクトを、変わりゆく事業要件に合わせて維持管理されるように、ビジネス・インパクト分析(BIA)やリスク・アセスメント、レビューを定期的に行なう必要がある。 2．ITサービス継続性管理の上位計画（ＢＣＰ）との関係緊急災害時などに、長期間、オフィスが立ち入り禁止になったり、ITサービス継続性が失われたり、スタッフが全員仕事に戻れない状況になったりなどで、事業が継続できなくなったとしたら、経営損失が出ることを経営層は責任を負う必要がある。従って、事業顧客は、事業継続性計画(BCP)を策定するBCMマネージャを任命するべきである。しかしながら、BCPの大部分は、ITサービスやIT環境にまつわることなので、ITSCMマネージャが、BCP案を元に、自社のITをどのように復旧させるか

14. 14 について管理しなければならないので、BCPとITSCM は、密接な関係にあるといえる。 3．ITサービス継続性管理の課題、重要成功要因、リスク課題：　ビジネス継続性マネジメント(BCM)がないことが課題となる。BCMプロセスがないと、IT側は、事業顧客の戦略を理解しておらず、IT側に都合のよいプロセスと優先度により、ITサービスを復旧しようと試みるため、安易に、事業顧客の意図しない高価なITソリューションを購入することになる。もしくは、災害時には、 ITが全て何とかしてくれるだろうと思い込み、事業の継続性と収益が失われることになる。重要成功要因：　ITサービスが顧客事業の達成目標を実現するために供給されていることを認識し、そのために復旧作業ができるようにする。復旧オプションのためのサプライヤとの契約が適切に締結されている。また、顧客事業の経営層、IT側の上級マネージャ、全ての従業員が、事業継続計画およびITサービス継続性計画に対する意識があることが、CSFとなる。リスク：　BCMがなく、ITSCMが単独で存在していること。また、ITSCMがあったとしても、情報が古くなっており、事業のニーズとの整合性がとれていないこと。事業顧客側から、BCMのあるITSCMを策定するための事業計画、事業戦略などの十分な情報がなく、それゆえ、予算を正当化できないこと。技術的な課題にばかり焦点がいき、事業のニーズや優先度に焦点があてられていないこと。　 4．ITサービス継続性管理の活動 BCMに沿ったITSCMの方針を立て、BCMプロジェクトを立ち上げる。ITSCMは、ビジネス・インパクト分析により、災害によってもたらされる被害事項を知り、また、リスク・アセスメントを行い、その組織の脆弱性の程度を知ることを要件として、戦略となるリスクの軽減をどこまで行なうかと、もう1つの戦略である、復旧オプションをどれにするかを決めて、初期テストを行なってみる。そして、経営層からユーザまで組織全体に、事業継続性についての意識を啓蒙し、実際の手順について教育を行なう。そこまでの活動を通して、レビューと監査を行い、再テストを行い、問題がなければ、変更管理に渡して、ITSCMの活動はいったん完了するが、引き続き、事業の変化に応じて、改訂を行なっていく。 1．インフラが損害を受け、サービスが停止する可能性において、どのような損害が発生するか ① 　一名体制のIT部員が、海外で交通事故にあい、現地で入院。その間、障害が起きたメールサーバにアクセス出来なくなり、取引先との連絡が一ヶ月以上途絶えて、取引停止となった。 ②　メール情報漏洩と経営不正が、マスコミに公表され、会社の評判が著しく落ち、IT担当者全員含む、社員の4割が即日退職し、社内ITインフラが停止した。そのため、ITサービスに依存していた全業務が停止し、倒産した。 ③　社内で傷害事件が発生し、警察が調査に来て、IT が、入室管理履歴を調査して、犯人を特定していた。その間に、全ての入室装置サービスが長時間停止してしまい、業務に支障をきたして、顧客との取引が停止になった。 ④　火災により、データセンターに設置していたサーバが焼失。Web業務アプリケーションサービスにアクセスできなくなり、締め日が終わってしまい、米国本社の経理システムが自動クローズされてしまい、修正不可能になり、部門長が、米国本社から責任を追求された。 ⑤　津波により、外部インターネットにアクセスできなくなり、オンラインバンキングを使用しての取引先への振込が間に合わず、企業としての信頼を失った。 ⑥　地震の影響で、ファイルサーバがダウンしたため、営業が（米国本社が作成した）新製品のプレゼン・テンプレートのダウンロードが不能。コンペに間に合わず、競合他社が勝ってしまった。 ⑦　震災で、電話回線がダウンし、テクニカルサポート・ホットラインの受発信ができなくなり、テクニカルサポートを求める顧客からの電話がとれず、信頼を失った結果、多数の顧客からサーベイで低い点数をつけられ、部門長が、米国本社から責任を追求された。 ⑧　震災で、FAXが不通となり、DELAのポリシーにより、契約FAX番号からしかFAXで送れない、HDDロック解除マスターキーが、DELAから受け取れず、社長の HDDのローカルにしかない資料をメールすることが出来ず、取引先に多大な迷惑をかけて取引停止にいたった。 ⑨　火災により、入室管理システムが壊れ、社員がオフィスに入る事ができなくなって、一ヶ月が経過し、顧客から解約の申し込みが殺到した。

15. 15 ⑩　地震の振動により、部門で独自にたてた開発用Unix サーバが物理的に破壊され、開発プログラムの納品が遅れたため、その顧客との取引契約が解除された。この事業顧客では、下記のように、ほぼ完全な、「即時的復旧オプション」を用意しているので、上記のことは起きない。 IT人員関連：同じ業務がこなせる人員を、複数の国に配置しているため、リモートからのサポートや長期出張によるサポート体制をとることが出来る。メール関連：スマートフォンから、海外に設置している、 GoodLink サーバ経由、または、Blackberryサーバ経由 7 で、メールの送受信が可能。その地域の電話インフラがダウンしている場合に備えて、そのスマートフォン・ハードウェアとキャリアは、どの国の通信方式にも対応しており、そのまま持って国外に移動することも可能。アドレス帳は、AD(+ Exchangeサーバ)と同期をしているので、いつでも検索可能。メールサーバがダウンしている場合は、アプリケーション管理機能と技術管理が、24時間365日オンコールで修復可能。 LAN関連： PCを緊急用アウトラインにケーブルをつなぎかえるか、会社支給のスマートフォンによるテザリングか、データカードでインターネットに接続し、VPN接続すれば回避できる。地域全体のインターネットインフラがダウンしている場合は、全ての業務をAPACタイムゾーンの別の支社の社員に業務を分担。もしくは、香港オフィスか台湾オフィスで出張勤務する。 PC関連: 7 米国Good Technology社の開発した、モバイル・データ・ソリューション・ツール。Androidフォンやi-phone とMS Exchange Serverを接続し、メールの送受信が可能。http://en.wikipedia.org/wiki/Good_Technology 災害等で、PCが全部破壊されている場合は、海外支社に、古いモデルのPCを全台保管しているので、それらのPCを最寄りの海外支社から取り寄せ、Altiris ツールを使用し、フランス支社からネットワーク経由でPC ビルドする。ローカルデータは、Mozy online backup 8 を使用して、即時、復元可能。HDDロックがかかってしまったPCのローカルデータも、Mozy online backup 経由で、別のPCに復元可能。ホットライン関連：地域の電話インフラ全体がダウンしている場合は、他の国のテクニカルサポート部門で代行可能（地域語対応の技術社員がいる）。サーバの物理障害関連：壊れたサーバは、現地ITが不在の場合、ドイツ支社に空輸され、DELLの国際ワランティーにより無償で修理され、データはドイツのITによって移行され、数日で使用可能。サーバ障害関連：全ての海外支社のほぼ全てのサーバが、米国本社で、一括管理されており、二重化されているので、米国本社以外で起きた共有サーバ障害に関して、データの同期をとる作業は不要である。情報セキュリティ管理 1．情報セキュリティにおける「CIA」 Cは、 Confidentiality（機密性）- 情報を知る権限を持つ人だけに閲覧可能にすることにより、機密性が高い状態であり、I は、Integrity（完全性）- 情報が完全でかつ正確で、許可されていない外部からの修正から守られていることで、完全性が高い状態であり、A は、Availability （可用性）- 必要なときにすぐに利用可能であるとか、障害が発生すれば、すぐに復旧できるか、そもそも障害に対して防衛策があり、可用性が高い状態であること。かつ、外部の企業との情報交換する場合に、その取引情報が信頼できるものとなっていること。CIAは、IT技術的な側面からだけではなく、オフィスへの侵入など物理 8 米国シアトル市にある、EMC社のオンラインバックアップツール。

16. 16 的な側面からも、ビジネス・プロセス全体に渡って、保護されなければならない。 2．情報セキュリティ管理における課題、重要成功要因、リスク課題：　情報セキュリティ委員会が機能していない。なぜならば、上級マネジメントの支持が得られておらず、計画立案をしていない。事業顧客は、その重要性を認識していたとしても、IT（特に、外部サービスプロバイダの場合）がなんとかしてくれるであろうと考えており、上級マネジメントとの話し合いがなされていない。たとえ、計画立案されていても、プロセス実務者に、その必要性が十分説明されていない。結果、ユーザは、誰もセキュリティ規約を守らず、事故が起きてしまってから、例えば、たった一通のメールの誤送信が起きた場合でも、全社員のリソースを使用して、調査がはじまるものの、対応手順が確立されていないので、膨大な時間を要し、事業の継続性が失われる。事業顧客が重要と考えるセキュリティの認識が、IT部門と整合性がとれていないことも課題となる。重要成功要因：　第一に、事業がセキュリティ妨害から保護されており、サービスデスクに報告される違反件数が少ないこと。上級マネジメントと事業顧客の間で、事業ニーズと一体化した合意済みの方針があり、ユーザに、その防止策が浸透していること。プロセス実務者、ユーザなど組織全体に、繰り返しトレーニングがなされていること。セキュリティ手順が、正当化され、適切で、上級マネジメントに支持されていること。変化していく環境に応じて、手順とコントロールに関する改善案が数多くあがるような、改善の仕組みがあること。リスク：　可用性と堅牢性に対する要件の増加に対応しなければならないリスク。スマートフォン紛失、ウィルス感染、外部からの侵入など、ユーザの意図しない原因により、個人情報を外部に流出させてしまうリスク。ユーザが、意図的に社内情報を外部に持ち出すリスク。事業顧客側が、ISMに従って行動しないリスクがある。将来の事業戦略に対する計画の認識不足や、予算不足により、効果的にISMが実施できないリスク。 1．情報セキュリティ施策 a. 入退社に伴う事故対策目的 - 　Tool上でNew Hire requestが生成されると、 Windowsアカウントが自動生成されるが、AD上で、 Outlookから見えないよう設定を治しておき、確実に出社が黙視確認された後に（離れているオフィスの社員の場合は、本人と連絡がとれた後）、見えるように設定する。（まだ社員ではない人間の個人情報保護） - 　Tool上でTermination Requestが生成されると、 Windowsアカウントが自動でDisableされるが、最終出社日を人事部と本人に確認し、MS Outlookから見えないように設定する。（もう社員ではない人間のプライバシー） - あらゆるアクセス権の追加には、そのユーザ直属の上長からの申請があった場合のみ可能。 - 　退職者のWindowsアカウントがAD上で無効化されているか確認し、hostnameを無効にし、Unixアカウントも無効にし、全てのDistribution Listや、アクセスグループから削除する。 - ファイルサーバのフォルダごとのアクセス権管理がなされているか確認する。 - 退職者の回収リストを作成して、全てのアセットを確実に回収し、部門長のサインをもらう。 - 退職者のローカルデータは、丸ごとDVDに焼いて、部門長に渡して、サインをもらう。 - 退職者のHDDは、規定の時間以内に復旧不可能なレベルでフォーマットする。 - 部屋によって、入室できる人を最低限に制限したアクセスカードを作成し、入室の必要がなくなったら、規定時間以内に、システム側で変更。 b. リーガルセキュリティ目的 - 人事部からの要請があった場合、ユーザ個人のVPNアクセス履歴、ログオン履歴、インターネットアクセス履歴などを開示する。 - 情報セキュリティ委員会の規定作成に関わり、調査、提案、ドキュメントのアップデートを行なう。 - 退職者のメールデータであっても、一定期間、訴訟ホールドしておく。 9 - 不正がないように、ソフトウェア・ライセンスの移行状態を正確に把握する。 9 訴訟が起きた場合、メールを保存していないと、企業に不利になることがあるので、Exchange側で、設定しておく。

17. 17 c. 情報漏洩保護目的 - PCを鍵のかかる倉庫に保管し、入出庫するときは、 10分程度の一時的な出庫であっても、紙に記録する。 - PCには、唯一のハードディスクパスワードをかけて配布する。 - メール誤送信を防ぐため、MS Outlook 2010の宛先オートコンプリート機能はオフにしてから、ユーザに PCを提供し、ユーザにも、オンにしないよう誓約させる。 - 3回の誤入力パスワードをトリガーとしてアカウント・ロックがかかるようにする。 - 全てのパスワードは、可能な限りシステム側（グループポリシー等）で強制的に、複雑なものしか設定できないようにするとともに、規定の日数が経過した場合は、変更を求めるように設定する。 - 全てのパスワードを紙に書く事は禁止している。 - パスワードやRSA Token などのPINコードを他の 10 ユーザに言う、代行ログオンは本人の許可があっても 100%禁止している。 - スマートフォンやノートPCや、RSA Tokenが手元にないことに気がついた時点で、ITか情報セキュリティ委員に電話で報告するよう、ユーザに誓約させる。 - 個人所有PCから、MS OWA 経由でメールサーバに 11 アクセスした場合は、添付ファイルを個人PCに保存しないよう、誓約させる。 - ユーザ席にあるPCは全て、ケーブルロックするよう、ユーザに誓約させる。ウィルス侵入、外部侵入対策目的 - Windows Firewallは、ユーザがオフに出来ないよう、グレーアウトさせて、PC配布。 - 　ウィルスはサーバ側で自動検知、駆除するように設定し、感染アラートを自動リポートする。自動駆除でき 10 RSA社が開発した、安全なVPN接続可能にするシステム。http://en.wikipedia.org/wiki/SecurID 11 ブラウザがあれば、どのPCからでも、メール送受信ができるマイクロソフト社のシステム　 http://en.wikipedia.org/wiki/Outlook_Web_App ていなかったら、ユーザに連絡をとり、PCのリビルドを行なう。 - PC側のMcAfee EPO Agent が、ウィルスを自動検出 12 し、自動駆除出来ずに、警告メッセージが表示された場合は、ITサービスデスクに速やかに報告させる。 - IMゲートウェイで監視できない、IM 以外は、インス 13 トールして使用してはならない。 - 外部ベンダーが社内で仕事をする場合は、NDAにサインをしてもらう。 - 外部ベンダー用の貸し出しPCは、ドメインにログオンできないよう、ローカルログオンに設定し (WirelesSLANを使わせないため)、アウトライン接続して作業してもらう。需要管理 1．需要管理 12月には、年賀カードがよく売れる、経理部スタッフは、毎月月末は非常に忙しいなどという、事業顧客の事業活動パターンやユーザ・プロファイルを把握、予測、分析し、サービス資産のキャパシティやパフォーマンスが過不足なく提供されることを、キャパシティ管理と共にコントロールしていくプロセスである。需要管理に固有なプロセスとしては、事業の繁忙期を拡散させて、特定のサーバへのアクセス量をコントロールするような、奨励、罰則などの戦略によって、需要に影響を与えることと、事業目標数値達成とIT投資の両方のバランスをとる方策をさぐることである。 2．需要管理と一番密接な関係にあるプロセスはどれかキャパシティ管理プロセスである。どちらも、事業成果実現とIT投資の最適化を目標とするが、次の点で異なる。需要管理は、ややビジネスとユーザ寄りのプロセスであり、事業顧客が、自らの顧客に対し、格差課金をもうけ、繁忙期を拡散するなどして、製品需要の調整を図るのを受けて、ITサービスの需要を予測して、戦略を立てる。一方、キャパシティ管理は、ITサービスと技術寄りのプロセスであり、需要管理から受けた需要情報によ 12 マカフィー社のセキュリティソフトのクライアントツールhttp://en.wikipedia.org/wiki/McAfee_VirusScan 13 AOL, MS Messengerなどのインスタント・メッセージング・システムであり、社外のアカウントは登録できないようサーバで制限している。2014年4月現在は、 Microsoft Lyncで統一している企業が多い。

18. 18 り、サービス資産のキャパシティやパフォーマンスが過不足のないように管理する。このように、キャパシティ管理の仕事は、需要管理から引き継がれていること、また、需要があるから、キャパシティが必要になることからも、これらのプロセスは密接な関係にあると言える。 3．コアサービスと支援サービスコアサービスとは、例えば、メールの送受信ができるなど、顧客にとっての基本的なサービスである。それに対して、支援サービスとは、顧客の要望に合わせて、ドミノサーバであったり、Exchangeサーバであったり、 Office 365であったりと選べて、更に、メールの送受信が、24時間365日可能であることを保証するなど、顧客にとっての付加価値を提供する、魅力サービスである。これらの組み合わせは、サービス・パッケージとして顧客に提示され、サービス・プロバイダは、これをサービス・ポートフォリオ管理に組み入れ、購入/導入を検討する。同時に、このコアサービスと支援サービスの組み合わせで、顧客の事業活動パターンとユーザ・プロファイルに適合するか、需要管理にて検討することになる。 4．需要をコントロールする方法需要管理が、事業活動パターンとユーザ・プロファイルを分析することによって、どのユーザが、どのサービスを、どの時期（どの時間帯）に、どのくらい必要とするのかを事前に知る。それによって、ユーザが、期限までに入力しないと経費の振込が来月に繰り越されるなどの罰則をもうけて経費精算システムの使用を平準化させてコントロールすることがある。また、キャパシティ管理が、事業環境の変化を把握し、新しい技術やサービス要件をサービス・ポートフォリオに反映し、リソース予測を正確にすることで、需要に対応することも、需要をコントロールする方法といえる。 1．ビジネスの事業活動パターンパターン：Webタイムシートの入力の締め日が、毎週金曜日の22:00なので、金曜日の17:25 – 17:35の間に、 7000ユーザが一斉にアクセスし、ユーザから見たパフォーマンスが落ちる。また、サーバがダウンする可能性もある。背景：　金曜日にまとめて入力する人が多く、金曜日の 17:25くらいにならないと、退出時間が不明、また、金曜日なので、残業する人も少なく、17:35以降に入力させることも難しい。月曜日の朝に入力したのでは、締め日を過ぎており、毎日入力したとしても、金曜日の夕方も入力しなければならない。対応策：　毎週木曜日の朝に、7000人に、一斉メール配信で、「タイムシートの入力締め切り金曜日22:00のお知らせ」を出す事により、パート社員など退社時刻が予めわかっているユーザには、月〜金の分まで、木曜日の空いている時間に、入力してもらう事を期待している。将来的には、不可分散の措置をとる予定である。第3章　RCVについて RCV（Release, Control & Verification)「リリース、コントロール、および妥当性」について、以下の通りまとめた。 ITILで示している管理プロセスに該当するもの変更管理プロセストリガ: 　IT組織をローカルベースから、ワールドワイドベースへ変更して、コスト削減（組織変更）インプット: 米国本社から、ワールドワイドで、OSをローカル言語から英語に変更するという、サービスポートフォリオ管理への変更要求。（インパクトが大きい重大な変更なので、サービスポートフォリオ管理への変更要求が必須）インターフェイス：　移行の計画立案およびサポート、変更評価プロセスアウトプット：　許可された変更がアウトプットされ、移行の計画立案およびサポート管理に渡される。 1．RCVにおいて活動するマネージャやスタッフの役割 (1)サービスの妥当性管理およびテスト ①　サービス・テスト・マネージャテストの中立性を保つために、リソース管理および展開管理に責任を負う者以外を割り当てなければならない。SD段階で、テスト条件、テスト・スクリプト、テスト・データ・セットの設計と計画を支援する。テスト・リソースを割り当て、テスト方針を遵守させる。リソース管理および展開管理が行なったテストを検証する。テスト環境を管理する。テストの進捗、テスト成果物、成功率、課題とリスクについての管理レポートの提供を行なう。 (2)リリース管理および資産管理 ①　リリースおよび展開マネージャ

19. 19 テストの中立性を保つために、サービスの妥当性確認およびテストを担当する者以外を割り当てなければならない。技術管理やアプリケーション管理などの機能からのリソースを含む、全てのリソースを計画し、調整する。ツールとプロセスに関する支援を計画、管理する。変更許可を必要とするあらゆる活動の前段階で、変更許可管理プロセスを支援する。変更管理、サービス資産管理と構成管理、妥当性とのインターフェイスの調整をする。 ②　初期サポートスタッフ技術管理やアプリケーション管理の機能の要員であり、パッケージ化と構築の実務者、または、展開の実務者が割り当てられることが多い。展開から最終的受け入れまでの期間に、ITサービスと事業機能をサポートするサポート文書を提供する。リリースを受け入れる。初期の段階のインシデントやエラーの対応を、サービス・オペレーションに対して支援する。サービス・オペレーションへの移行を取り扱う。問題管理を行い、RFCを提起する。サービス・リスク・アセスメントを行なう。 (3)サービス・ナレッジ管理 1．ナレッジ管理プロセス・オーナ多くの組織では、同プロセス・マネージャと兼任され、また、サービス資産管理および構成管理の役割と兼務されている。組織内のナレッジの識別、取得、維持のための全体的なアーキテクチャを作成する。プロセス戦略を定義し、プロセス設計を支援する。プロセス文書を最新の状態に保つ。プロセスの方針と標準を定義する。コンプライアンス確認のために、定期的に監査を行なう。プロセス戦略をレビューし、変更する。課題に対処するCSI 管理とそのレビューを行なう。マネージャの役割リリース管理および展開マネージャ概要: Windows XPから、Windows7へのアップグレードに伴う、デバイスドライバ、標準ソフトウェア、セキュリティパッチのパッケージリリース役割: 1) リリースと展開の計画立案。Windows XPから Windows7へ移行するに当たり、デバイスドライバを新 OS対応のものにパッケージし直す。リリース・パッケージには、手動でのインストール手順書、前ヴァージョンからの改良点の文書など複数のリリース・ユニットを含める。問題発生時の切り戻しのため、アンインストールの合否もテスト項目に含める。2)リリースの構築。ストックホルム、シドニーのパッケージャーに、リリース・パッケージ作成依頼する。3) 妥当性確認テスト。担当パッケージャーとコミュニケーションをとりながら、日本語Windows7上にて、SCCM 経由にて、テ 14 ストPCへのリリース・パッケージをインストールし、動作テスト手順項目に従って、テストを実施。不具合があれば、問題チケットを発行し、開発チームにリ・アサインし、パッケージの改良を行なう。完全性を保護しながら、新しい機能性を提供できることを確認する。有用性と保証があることも確認する。3) 確定版メディアライブラリに登録するために、変更管理プロセスから許可を取る。動作テスト手順項目表にて問題項目がなくなったら、変更管理プロセスに変更許可依頼する。4) 展開。受理されたら、SCCM経由で、テスト・デスクトップ・イメージングをし、新イメージ全体のテストを実施する。パイロットユーザ（Early Adaptors）への展開する。5) SDP通りにサービスを定着させる。　6) サービスオペレーションに予測されるトラブル等を伝え、引き継ぐ。　7)レビューとクローズ。パイロットユーザに、悪い影響がなかったことを確認し、確定版メディアライブラリに登録する。Windows7マシン配布済みの全ユーザ7000人にプッシュ配布し、変更要求チケットをクローズする。 1．サービス・マネジメントにツールを利用することの利点サービス・デザイン・プロセスが、より効率的に機能するという利点がある。具体的には、効率と効果、弱みと改善の機会を特定し、管理情報を提供する。マネジメント・コストを削減し、ITサービスの生産性を向上させる。ITサービスの品質を向上する。重要なプロセスの集中化を行い、サービスマネジメントの中核的プロセスの自動化と統合を行なう。データが集まって、情報となり、それがナレッジになることで、傾向を明確化できるという利点がある。 2．サービストランジションの課題、重要成功要因、リスク課題: STには、IT組織だけでなく、財務、技術、人事など、たくさんの人が関わるので、システムが、複雑になりがちである。多種多様な顧客、つまり、多様な窓口の管理が必要となる。そのため、調和や統合がほとんどな 14 マイクロソフト社が提供する、ソフトウェア展開、資産管理システムツール; System Center Configuration Management http://technet.microsoft.com/ja-JP/systemcenter/bb507744. aspx

ITIL2011 to ITIL4 transition baseline guidance 【Continuous Study】

ITIL2011 to ITIL4 transition baseline guidance 【Continuous Study】

ITIL2011 to ITIL4 transition baseline guidance 【Continuous Study】

Recomendados

Mais conteúdo relacionado

Similar a ITIL2011 to ITIL4 transition baseline guidance 【Continuous Study】

Similar a ITIL2011 to ITIL4 transition baseline guidance 【Continuous Study】(10)

Mais de Jerimi Soma

Mais de Jerimi Soma(20)

Último

Último(8)

ITIL2011 to ITIL4 transition baseline guidance 【Continuous Study】