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