ITILファウンデーション サービスオペレーション

□サービスオペレーション

　問い合わせの受付や、障害に対処するなどの活動で合意済みのサービスレベルでITサービスを提供できるようにする。

サービスオペレーションプロセスの概要

・イベント管理

　ITサービスの提供に必要なサーバ、アプリケーションなどから通知されるすべてのイベントを監視し、異常状態を通知するイベントが発生した場合にインシデント管理プロセスにエスカレーションする

・インシデント管理

　できるだけ早くインシデントを取り除くことを目的とする活動を行う。その為、インシデント管理プロセスでは根本原因の調査や解決などは行わない。

・問題管理

　問題の根本原因の特定、除去を目的とする活動を行う。原因を特定できると変更要求を変更管理プロセスに依頼する。

・要求実現

　ユーザから要求されるリスクが少なく低コストで発生頻度が多い作業をあらかじめ合意された手順に従って処理する。

・アクセス管理

　許可されたユーザにITサービスを使用する権限を付与、付与された権限が適切に使用されているか確認する。

サービスオペレーションの機能の概要

・サービスデスク

　ITサービスプロバイダとユーザ間の接点となる組織。インシデント、サービス要求、標準的な変更を受付、処理する。

・IT運用管理

　　ITインフラストラクチャを継続的に管理、保守し合意されたレベルでITサービスを提供するために必要になる

・技術管理

　ITインフラストラクチャを継続的に管理、保守し合意されたレベルでITサービスを提供するために必要な技術力やリソースを提供する

・アプリケーション管理

　運用中のアプリケーションの管理とサポートを担当する。

サービスオペレーションにおけるコミュニケーション

　コミュニケーションの要件

・運用に関する日常的なコミュニケーション

→サービスオペレーションの定期的な活動を調整する

・シフト間のコミュニケーション

→シフト制でのシフト間の引き継ぎ

・パフォーマンス報告

→ITサービスのパフォーマンスなどを報告

・プロジェクトにおけるコミュニケーション

→プロジェクトの目標や進捗の確認を行う

・変更に関するコミュニケーション

→変更管理プロセス、リリース管理、展開管理プロセスを支援する

・例外に関するコミュニケーション

→インシデントや予想外の活動やパフォーマンスの報告をする

・緊急事態に関するコミュニケーション

→インシデントのインパクトや重大度を調査して確認し実際に緊急事態であることを確認する

・グローバルなコミュニケーション

→複数の国に跨ってサービスを提供する場合、様々な国のユーザ・顧客・ITスタッフ間でグローバルにコミュニケーションをとることで運用リスクを下げる

・ユーザ及び顧客とのコミュニケーション

→顧客またはユーザの要件を満たすために顧客とコミュニケーションをとる

□イベント管理

イベント：CPU使用率が許容できる稼働率を超えている、バッチジョブが異常終了したといったITサービスの管理にとって重要な状態の変更のこと

情報・警告・例外に分類され、通常はイベント管理ツールを用いて管理されている。

□インシデント管理

ITサービスに対する計画外の中断や品質の低下を管理する。

重要なことはインシデントを漏れなく管理すること、解決までのステータスを追跡すること。

インシデント：ITサービスの計画外の中断や品質低下のこと

インシデントが報告される経路

・サービスデスク経由

・イベント管理プロセス経由

・技術スタッフ経由

インシデントモデル

特定の種類の再発するインシデントの処理手順を定義しておくこと

定義する項目

・インシデント処理手順

・処理手順の優先度

・責任

・データやファイルのバックアップなどインシデントの解決前の予防策

・処理を完了するまでの許容期間、閾値

・エスカレーション手順

・エビデンス保持

重大なインシデント

事業に深刻な中断を与える原因となるインシデントのこと

インパクト

インシデント、問題、変更によるビジネスに与える影響の指標。

緊急度

インシデント、問題、変更が事業に顕著なインパクトを与えるまでの時間の指標

優先度

優先度＝インパクト＋緊急度

エスカレーション

インシデントをタイミングよく解決できるようにするための仕組み

・機能的エスカレーション

インシデント解決をするために、より専門的なグループに引き渡す

１次サポート　サービスデスク

２次、３次サポート　インシデントを解決するためのより高度な専門スキル、リソースを所有しているグループ

・階層的エスカレーション

重大なインシデントの場合、上位のITマネージャに情報を提供すること

インシデント管理プロセスの活動

・インシデントの識別

・インシデントの記録

・インシデントの分類

・インシデントの優先度の決定

・初期診断

・インシデントのエスカレーション

・調査と診断

・解決と復旧

・インシデントのクローズ

要求実現

問題管理

アクセス管理

技術管理

アプリケーション管理

IT運用管理

継続的サービス改善

テミングサイクル　PDCAサイクル

①ビジョンは何か

事業とITサービスの最終目標を常に意識し、改善の方針にブレがないか確認する

②我々はどこにいるのか？

現状分析し、ビジョン達成に必要な作業を明確にする

③我々はどこを目指すのか？

目標の設定

SMART

Specific

Measurable

Achievable

Relevant　当面の目標にとって適切である

Time-Bound 今取り組むべき内容である

④どのようにして目標を達成するのか？

どのようにプロセス改善を行うかをCSI管理表にまとめる

⑤我々は達成したのか？

改善がちゃんと実施できたのかKPIを用いて計測する

⑥どのようにして推進力を維持するのか？

ベースライン

改善前と改善後の差分を明確にする為に、基準値を設定すること

監視、測定する理由

妥当性確認

意思決定がビジョン通りなっているか確認する

方向付け

意思決定のプロセス妥当性を確認する為

正当化

サービス提供側の正当性を証明する為

介入

変更や是正措置が必要な箇所を特定する為

測定基準

技術測定基準

可用性やパフォーマンスなどITサービスを構成するコンポーネントの測定基準

CPU使用率　メモリ使用量

プロセス測定基準

KPI　CSFを測定する

CSF 成功に必要な観点　コスト削減　品質向上など

KPI　CSFを達成する為に達成すべき指標

サービス測定基準

技術測定基準とプロセス測定基準を用いてサービスとしての測定基準を算出する

サービス・ライフサイクル全体でのITガバナンス

ガバナンス

不祥事を起こさない組織を作ること

コーポレートガバナンス

外部の法規制やフレームワークに適合すること

SOX法など

ITガバナンス

ISO/IEC38500

７ステップの改善プロセス

①改善に対する戦略の識別

ビジョンの明確化

②測定対象の定義

③データの収集

④データの処理

集めたデータをCSFやKPIが達成できたかわかるように加工する

⑤情報とデータの分析

改善の分析をおこなう

⑥情報の提示、活用

レポートにまとめる

⑦改善の実施

USCPA FAR1-3

1. Basic Concept of financial statement

1-1 GAAP　Generally Accepted Accounting Principle
USGAAP 　FASBにより制定される
IFRS 　　　IASBにより制定される

1-2 IFRS


世界各国でIFRSへの移行が進んでいる

・IASB FASBによるノーウォーク合意　２００２年

USGAAP　Rule-Based
IFRS           Principle-Based

1-3　The structure of IFRS
IASC 　IASBの前身



1-4 The Structure of US GAAP
２０００年代後半までUSGAAPは多数の基準策定者によって原則が作られていた為、基準や規定が爆発的に増えた
→利用者にとってわかりにくいかたFASBが１つにまとめる！！

ASC　Accounting Standards Codification
目的
1.ちゃんとカテゴライズしましょう
2.今までの内容は正確に反映しましょう
3.常にアップデートできるようにしましょう
ここで確認できる　http://www.fasb.org/home

・ASCの構造と形式



トピック　会計のテーマ　リース　棚卸など
サブトピック　項目　テーマをブレイクダウンしたもの
セクション　区分　項目に関する認識、測定のルールをまとめている
サブセクション　区分のさらなる詳細、実務的なことをまとめている

1-5 Definition of Recognition and Measurement
ASCのセクションでは認識と測定について規定されている
認識　資産、負債、収益、費用を財務諸表に記載すること

測定　認識される項目を数量化すること
《数量化するときの指標》
取得原価 historica cost
再調達原価　replacement cost
現在市場価値　current market value
正味実現可能価額　net realized value
将来キャッシュフローの現在価値　present value of future cash flows

1-6 IASB FASB ,their Conceptual Framework
1-7 SFAC Statement of Financial Accounting Concepts

IFRS　USGAAPには含まれないが財務諸表の作成および基礎を成す概念がある

IFRS    
 the conceptual framework for financial report
※概念フレームワークのどの内容もIFRSを優先することはない

USGAAP
 Statements of financial accounting concepts
USGAAPを作成するときの指針となる
 USGAAPを構成するものではない

1-8 Hierarchies of Concepts within SFAC

財務会計概念書は下記の階層でまとめられている




1-9 The Object of Financial Reporting SFAC8
財務報告の基本目的をあげている
はじめはSFAC１であったが後にSFAC8に改定された

a)現在、将来の投資者、債権者が企業に資金提供を行うときの意思決定をするのに有用な財務情報を提供する
b)企業の資産や請求権についての情報を提供する

1-10 Qualitative Characteristics of Useful Financial Information
財務報告書が”有用 useful”である為の特性を挙げている

a) Fundamental qualitative characteristics
有用か否かを決める特性
・目的適合性 relevance  情報に価値があるかどうか
　予測価値 predictive value
　　将来の財政状態を予測させるような情報
　確認価値 confirmatory value
　　過去のことを説明し結果の因果関係をちゃんと明記する

　重要性 Materiality
 
・忠実な表現　faithful representation
情報が信頼できること
網羅的  complete　漏れがないですよね
中立的 neutral　見積もりや減損に偏りがないですよね
重要な誤りがない　free from error　

b) Enhancing qualitative characteristics
Comparability 比較可能性
会計期間の統一など
Verifiability　検証可能性
後から検証できること
timeliness　適時性
新鮮じゃないといけない。だから１年に１回決算する
understandability　理解可能性
利用者は会計に専門知識があるわけではない　わかりやすく

1-11 Recognition and Measurement(1) Overview & Basic Assumptions


　
基本的前提 Basic Assumption
Economic entity assumption 会社単位で財務情報をまとめること
going concern assumption　法人は死なない前提
monetary unit assumption　測定基準をアメリカドルに統一しましょう
periodicity assumption　会計期間を一定に区切りましょう

1-12 Recognition and Measurement(2) Principles of Accounting

あらゆる会計のルールは以下の４つの基本的原則に立脚している
a)historical cost principle
資産の評価基準として取得原価を用いること
客観的で検証しやすい為

b)revenue recognition principle
収益をいつ認識すべきなのか？
・実現主義の原則 realization concept
 realizable お金を受け取った、受け取る権利を得た状態のこと
 earned 物やサービスを引き渡したとき

反対の意味としては現金主義、発生主義 accrual basis

c)matching principle
費用はいつ認識するの？
収益が計上された時に費用をひも付けて記録する

d)full disclosure principle
すべての情報を隠さずに記載しなければいけない

1-13 Recognition and Measurement(3) Constraints
会計のルールが受ける４つの制約
a)cost-benefit relationship
会計情報を提供することで得られる効果はそれを提供する費用を上回ってはならない
b)materiality
収益、費用、資産、負債の金額と比較して重要性が低い時は簡便法を用いて良い
c)industry practice
業界独特の慣習がある場合は独自の会計処理が認められる
d)conservatism
疑いがある場合は過大表示する可能性の最も低い方法を採る

1-14 Elements of Financial Statements SFAC6
財務諸表の構成要素

a)Assets
過去の取引の結果として発生の可能性の高い将来の経済的便益

b)Liability
過去の取引の結果として発生の可能性の高い将来の経済的便益の犠牲

c)Equities
負債を控除した後の思案に対する出資者の残余請求権

d)Investment by Owners
残余請求権を獲得、増加させる為に保加の事業体から価値のあるものを譲渡した結果、当該企業の持分が増加すること

e)Distribution to Owners
出資者への資産の譲渡や負債の発生などで当該企業の持分が減少すること

f)Comprehensive income
出資者以外の源泉からの取引、その他の環境要因から生じる一期間における持分の変動

g)revenues
財貨の引き渡しや用益の提供による資産の流入か負債の減少

h)expenses
財貨の引き渡しや用益の提供による資産の流出か負債の増加

i)gains
副次的な取引による資産の増加

j)losses
副次的な取引による資産の減少

1-15 　Using Cashflow information and Present Value in Accounting Measurement SFAC7
SFAC7が使われるのは
a)資産、負債を初めて認識するとき
b) a)を再度測定しなおす時　フレッシュスタート測定
c) 償却原価法において実行金利法を必要とする時

現在価値とは
定義
将来のキャッシュのイン/アウトフローを見積もり、それから利子率を引いた価値

算出方法
伝統的アプローチ
確率が一番高い現在価値を算出する
期待キャッシュフローアプローチ
可能性のある現在価値を発生確率を加味して算出する

ITILファンデーション 4.サービスデザイン

□サービスデザイン
サービスストラテジで明確にした要件をもとにITサービスの設計を行うこと

デザインする時に考慮すべきこと
機能性(ITサービスの機能・品質)
リソース(費用・スタッフ)
スケジュール（期間

４つのP

• 人（People）：プロセスを実現するのに必要な役割、人材像を明確化し、必要なスキル向上のためのトレーニング計画を策定し実践する。
• プロセス（Processes）：プロセス改善の目的（ビジョン）を明確化し、改善プロジェクト体制を構築し、 ITIL®のグッドプラクティスとのベンチマーキングにより改善課題を明確化して、作業フロー、手順書、重要業績評価指標（KPI：Key Perfomance Indicator）などを設計する。
• 製品・技術（Products）：プロセスの効率的な実行、作業負荷軽減、自動化による作業ミス削減のために、適切なツールを活用する。
• パートナー（Partners）：定型的な監視作業をアウトソーシングすることにより、作業負荷を軽減し、本来注力すべきシステム改善企画作業を推進する。

サービスデザインの５つの側面

サービスデザインでの設計対象のこと

・サービス

・サービスを管理するシステム、サービスポートフォリオ

・技術アーキテクチャ
・プロセスの活動、役割、責任
・測定方法と測定基準

サービスデザインパッケージ(SDP)
設計活動の成果物のドキュメント一式
・要件：事業要件、サービスの活用方法や場所　サービスの事業窓口
・設計：サービスの機能要件、サービスレベル要件、運用管理要件
・サービスライフサイクル計画：サービス移行の計画、運用戦略)

サービス自動化
サービスプロセスを自動化すること
《目的》
・サービス品質の改善
・ばらつきの減少による有用性、保証の改善
・コスト削減

自動化をするにあたり意識することとして
・自動化する前にサービス・プロセスの簡略化
・活動の流れ、作業分担を明確にする
・システムやプロセスとユーザの接点を少なくする(簡単なUI)
・単純・日常的でもないタスクとやり取りの自動化は急がない

□デザインコーディネーションとは
デザイン活動が円滑に進むように調整すること。

デザインコーディネーションプロセス
・サービスデザイン段階全体に関連する活動
複数のITサービスを新規に開発したり変更したりする場合に、適切な設計業務が行えるようにリソースと能力を調整する
①方針と方法の定義、維持
②設計のリソースと能力の計画
③設計活動の調整
④設計に関するリスクと課題の管理
⑤サービスデザインの改善

・個々の設計に関連する活動
個々の設計活動で、すべての要件が設計内容に反映されるようにする
①個々の設計の計画
コストやスケジュールの計画を立てる

②個々の設計の調整
関係者のスケジュール調整や顧客との要件の合意

③個々の設計のモニタ
後工程で手戻りが発生しないように
・合意した方法に従っているか
・他の設計活動と整合性があるか
・事業達成目標を支援する包括的な設計になっているか

④設計のレビュー、サービスデザインパッケージの引き継ぎ
・設計活動が方針や標準に従っているか
・すべての要件が満たされているか

□サービスカタログ管理
サービスカタログとは提供中/提供の承認がされているITサービスの情報が格納されているDBや文書

サービスカタログには
・事業/顧客サービスカタログ
顧客向けのサービスの詳細をまとめたサービスカタログ

門＼部門	営業1課	営業2課	営業3課	人事	総務	広報	購買
人事オンライン				○
受発注業務1	○	△					○
受発注業務2		○	○				○
Webポータル	△	△	○		△	○
電子メール	○	○	○	○	○	○	○
ヘルプデスク	○	○	○	○	○	○	○

・技術/支援サービスカタログ
全ての支援サービスの詳細をまとめたサービスカタログ


□サービスレベル管理
顧客と合意したレベルでITサービスが提供されているかを管理する


・サービスレベル要件(SLR)
 ITサービスへの顧客の要件のこと
サービスレベルアグリーメントの顧客との交渉時に使用される

・サービスレベルアグリーメント(SLA)
サービスプロバイダと顧客の間で交わされる合意

	項目	説明
可用性	サービス時間	ユーザーが受けるサービス提供時間ただし、 メンテナンス時間 は除く	24時間365日
	サービス稼働率	(サービス提供時間−停止時間）÷サービス提供時間100［％］	99.7%
	障害回復時間（MTTR）	障害を検知 した時間から、障害が回復してユーザーがサービスを受けれるまでの時間	1時間を越えないこと
	障害通知時間	障害が発生してから、ユーザーに障害が発生したことを通知するまでの時間	30分を超えないこと
パフォーマンス	応答時間	一定時間(1時間)内の全トランザクションの95%が含まれる応答時間	3秒以内（非ピーク時）5秒以内（ピーク時）
保全性	データ・ログの保全性	システム上のデータベース、ログの保持期間	ログ7日間データベース31日間

を定義する。

サービスプロバイダはサービスが運用中も常にSLAの基準を満たしているかモニタリングを行い、必要であればサービス改善計画(SIP)を提出する

・サービスベースのSLA
単一のサービスを規定し、そのサービスを利用する全ての顧客を対象とするSLA
・顧客ベースのSLA
特定の顧客グループとその顧客が使用する全てのサービスを対象とする

・マルチレベルSLA
SLAを階層構造で管理したSLA
e)企業レベル→顧客レベル→サービスレベル

・オペレーショナルアグリーメント(OLA)
ITサービスプロバイダ内の他の部署と交わされる合意

・外部委託契約(UC Underpinning Contract)
ITサービスプロバイダと外部サプライやの間で交わされる契約

・サービスレビュー
サービスの達成度や翌期の課題を顧客と定期的に確認するミーティング

・サービス改善計画 SIP
プロセス・ITサービスに対する改善を実施する為の正式な計画のこと

・サービスレベルアグリーメントモニタリングチャート　SLAMチャート
SLAが達成できているかをモニタリングする為の技法

SLA Monitoring Chart

＜SLA状況一覧＞

　　・SLA違反　　 ■

　　・警告レベル　■

　　・SLA達成　　 ■

＜日付別／サービスカタログ別に表示＞

・サービスレベルマネージャ

SLA,OLAの文書化に責任を持つ。並びにSLAが満たされているか監視する

□キャパシティ管理
費用を最小限に抑えつつ、ビジネスのニーズを満たすのに十分なリソースを用意すること

・リソースとコストのバランス
・需要と供給のバランス

キャパシティ計画
SLAやITサービスの将来の要件からどの程度のITリソースが必要になるかを予測、計画すること
→ITリソースの投資計画

キャパシティ管理のサブプロセス
・事業キャパシティ管理
将来の事業要件の把握を行う

・サービスキャパシティ管理
現在のITサービスで使用されているリソースと使用状況を収集・記録・分析

・コンポーネントキャパシティ管理
ITインフラストラクチャを構成するコンポーネントのキャパシティ、CPU使用率、メモリ使用量収集、記録、分析する
《コンポーネントキャパシティの測定項目　例》

• CPU使用率
• メモリ使用率トランザクション・タイプごとのプロセッサ比率
• IOレートとデバイス使用率
• 待ち行列の長さ
• ディスク使用率
• トランザクションレート
• 応答時間
• バッチ処理時間
• データベースの利用
• インデックスの利用ヒット率
• 同時ユーザ数
• ネットワークトラフィック量

□ITサービス継続性管理
 ITサービスに深刻な影響を与える可能性があるリスクを管理する。
→災害時でもすぐにビジネスを復旧できるような計画策定

・事業継続性計画 Business Continuity Plan
ビジネスプロセス中断後にビジネスプロッスを回復する為に必要なステップを定義した計画

・事業継続性管理 Business Continuity Management
事業に深刻なインパクト与える可能性があるリスクを管理する

・ビジネスインパクト分析
サービスが中断することによる事業へのインパクトを定量化すること
→復旧すべきサービスの優先順位を決定することができる

・リスクアセスメント
事業のリスク(+/-関係なく不確実性のあるもの)を識別して脆弱性を評価すること

・リスク分析
リスクの識別と評価、コストに見合ったリスクへの適切な対応策を特定

・リスク軽減手段
把握したリスクを軽減させる計画を立てる

・復旧オプション
サービスの中断に対応するための戦略。
システム復旧のための戦略として、
手作業のワークアラウンド
相互協定、段階的復旧（コールドスタンバイ）
中間的復旧（ウォームスタンバイ）
高速復旧（ホットスタンバイ）、即時的復旧（ホットスタンバイ）

に整理される

□可用性管理
ITサービスの可用性に関するSLA目標値を満たす為にサービスを最適化、改善していくこと
・コンポーネント可用性
サービスを構成するサーバやアプリケーションなどの可用性

・サービス可用性
サービスそのものの可用性

可用性
サービス・コンポーネント・構成アイテムが必要とされた時に合意された機能を実行する能力のこと

　　　　　合意済みサービス時間ー停止時間
可用性＝　ーーーーーーーーーーーーーーーー　×１００％
　　　　　　合意済みサービス時間

信頼性
サービス・コンポーネント・構成アイテムが中断せずにどれだけ長く合意された機能を実行できるか示す指標のこと（どの程度故障しにくいか示す）

信頼性の指標は２つある
・平均サービスインシデント間隔　障害が発生する時間の平均
　　　　　　　　　　　　使用可能な時間
信頼性(MTBSI(時間))=ーーーーーーーーーーーー
　　　　　　　　　　　　　中断回数
・平均故障間隔　合意済みの機能を中断なく実行できる時間の平均
　　　　　　　　　　使用可能な時間ー総停止時間
信頼性(MTBF(時間))=ーーーーーーーーーーーー
　　　　　　　　　　　　　中断回数
保守性
障害発生後、どれくらい迅速かつ効果的に通常の稼働状態に回復できるかを示す指標

　　　　　　　　　　　総停止時間
保守性(MTRS)＝ーーーーーーーーーーー
　　　　　　　　　　サービス中断回数

各指標の関係性

サービス性
サードパーティサプライヤを信頼性、保守性、可用性を総合して構成サービスを評価すること

重要事業機能(Vital Business Function)
ITサービスが関わるビジネスプロセスの中で最も重要な機能を表したもの

拡張版インシデントライフサイクル
検出・診断・修理・復旧・回復の段階がある。
インシデントインパクトを増大させたすべての要因を把握し、インパクトをコントロール、低減させる方法を計画するときに使用する
ダウンタイムを減少させるために、各フロー毎のダウンタイムの計測などを行う


□情報セキュリティ管理
組織の資産、情報、データ及びITサービスの機密性、完全性、可用性が事業部門と合意したニーズに対応しているようにする

可用性・機密性・完全性を考慮して管理することを意味する。（バランスが大切！！）

機密性　情報を知る権限を持つ人だけに公開されている
完全性　情報が完全かつ正確で、許可されていない修正から保護されている
可用性　必要とするときに、情報を入手および利用可能なこと


情報セキュリティ方針
情報セキュリティに対してどのように組織が取り組むかまとめたもの
一般的に
アクセスコントロール方針
パスワードコントロール方針
ウイルス対策方針
リモートアクセス方針
ITサービス、情報コンポーネントへのサプライやのアクセスに関する方針
を含める

情報セキュリティマネジメントシステム Information Security Management System
情報セキュリティ管理の目標を達成するための枠組み

□サプライヤ管理
サプライヤから投資に見合う価値を取得すること

サプライヤの分類
戦略的サプライヤ　戦略的機密情報を共有
戦術的サプライヤ　重要な商業活動でやりとりがある
運用上のサプライヤ　運用中のサービスの供給でやりとりがある　
コモディティサプライヤ 比較的容易にだいたい可能

契約
複数の当事者間における、法的な拘束力のある合意のこと

サプライヤ及び契約管理システム SCMIS
サプライヤの管理に使用される一連のツール、データおよび情報のこと

管理するもの
・各サプライヤが提供するサービス、製品の詳細、関連する構成アイテムの情報
・サプライヤとの契約内容

ITサービスの提供戦略　ソーシング戦略
アウトソーシング　I
Tサービスに必要なリソースを外部から調達する
インソーシング　　
ITサービスに必要なリソースを社内から調達する
コソーシング　　　
ITサービスに必要なリソースを外部と社内から調達する
パートナーシップ　
ITサービスに必要なリソースを外部から調達する
アプリケーション・サービス供給　
ASPが提供するアプリケーションを協定を結んで提供
ビジネスプロセス・アウトソーシング　
コストの安い地域にビジネスプロセスや機能をアウトソーシング
ナレッジプロセス・アウトソーシング
専門能力が必要なビジネスプロセスや機能をアウトソーシング
クラウド
需要に応じてクラウドサービスプロバイダにアウトソーシングする。

費用対効果とナレッジの蓄積、スピード感のバランスが大事

チケット設計メモ

チケット設計

AT&T

顧客の入力情報をもとに、ネットワークの自動テスト機能

アクセスライン、顧客ライン、Comラインか

→アラートが発生してないが、顧客が故障を検知するケースは？

Checkpoint

・顧客は故障が発生した後、どのような業務が発生しているのか？

・故障対応の原因調査でポータルの事前調査にて確認できるものは？

→顧客がチケット起票をしている間に自動的にテストを行う

→チケットを書き始めた時点でオペレータに通知がいく

ITIL ファンデーション 3 サービスストラテジ

□サービスストラテジ

サービスストラテジとは

提供するITサービスの競争優位性を保つ為に、何をすれば良いか計画すること。

有用性と保証を考えることでストラテジの評価を行うことができる

有用性

顧客が望んでいる機能、操作性、品質などをITサービスが提供しているか。目的適合性

保証

顧客がITサービスを使用するにあたって十分なキャパシティ、パフォーマンス、可用性を提供しているか。使用適合性

有用性と保証があることで、初めて「価値」を創出することができる

では、どのように価値をを向上させるのか？

リソースと能力を最適化することで向上させることができる

リソース→有形資産　お金で買える

能力→無形資産　お金で買えない

リソース＋能力＝サービス資産

ITサービスの戦略をまとめる為に必要な活動は

□ITサービス財務管理

ITサービスの供給に必要な資金の確保が目的。

予算業務、会計業務、課金に対する要件を管理する。

・会計業務

会計業務とはITサービスに必要なすべてのコストを明確にし、その管理方法を定めることです。必要なコストを分類し、正確なデータを作成することでITサービスに対する投資判断の裏付けとなる

ex)サービス指向のIT会計

購入品目毎に支出を管理するのではなく、サービス毎に支出を管理する。

・予算業務

ITサービスを提供するための支出を予測し、その予測した数値と実際に掛かかるコストとの差異を明確にし、監視、調整していくことです。予実の結果を客観的に評価することにより、コストオーバーしているサービスや重要性の低いサービスなどを洗い出し、ITサービスの停止や継続の意思決定を強化

・課金

顧客に対して、提供するサービスの対価を請求すること。

サービスに必要なコストとその付加価値を合算し、請求する価格を設定します。課金することにより、サービスプロバイダーはサービスの維持改善に対しての意識が強まり、より良いサービスの提供へと繋がっていく

財務管理を行う為に

・サービス査定

サービス査定とはITサービスに必要なコストを有形無形問わず洗い出し、さらにそのサービスによって生まれる付加価値を手量的に算定すること

・需要のモデル化

将来のサービス需要を予測し、顧客のサービスへの総利用コストを特定する

・ビジネスケース

主要な支出項目の正当性を説明するもの。コスト、利点、代案、課題、リスク、起こりうる問題などに関する情報を含む。

□需要管理

ITサービスに対する顧客の需要を判断し、その需要にキャパシティが対応できるようにすること

需要管理の為に必要な情報

事業活動パターン(PBA)

事業活動パターンを把握し、ITサービスの計画立案に使用する

PBAイメージ

ユーザプロファイル

ITサービスに対するユーザの要望パターンのこと

□サービスポートフォリオ管理

ITサービスが事業に提供する価値を明確にし、限られたリソース・能力の配分を管理する

ITサービスをサービスポートフォリオによって管理し、

サービスパイプライン

まだ顧客に提供できていないすべてのITサービスを格納せるDBや文書

サービスカタログ

顧客やユーザに提供されているITサービスまたは顧客やユーザと提供することが承認済みのITサービスの情報を格納するDBや文書

廃止済みサービス

段階的に停止、廃止されたサービス

□事業関係管理

顧客と良好な関係を築き、顧客や事業部門のニーズを把握することが目的

ITILファンデーション サービスマネジメント

□サービス
サービスとは
顧客に価値を提供する手段
顧客は特定のコストやリスクを負わずに期待する成果を実現する
ex) 電子メールシステムやビジネスポータル

サービスのカテゴリ
サービス提供先によるカテゴリ
顧客向けサービス
顧客から見えるITサービス。サービスカタログに記録される
　外部顧客向けサービス　顧客 ≠サービスプロバイダ組織
　内部顧客向けサービス　顧客＝サービスプロバイダ組織
　
支援サービス
ITサービスプロバイダが顧客向けサービスを提供するために必要とするサービス
ex)ネットワークサービス　ディレクトリサービス

サービスの機能・特徴によるカテゴリ
コアサービス　顧客が望む基本的な成果を実現するサービス
サービスレベルが低ければ低いほど顧客は不満を感じる。レベルが高ければ高いほど顧客は満足を感じる。

実現サービス　コアサービスを提供するために必要なサービス
必要不可欠なサービスのため、提供されないと不満を感じるが、提供されても顧客の満足度が上がることはない。

強化サービス　顧客にとってコアサービスをより魅力的にするために追加されるサービス
提供されないことで顧客が不満を感じることはない。しかし、提供されることで顧客の満足度が高まる可能性がある。

※時間とともにコア・実現・強化の顧客の考え方が変わってくる
ex）
コアサービス:宿泊場所の提供と本来のサービス。
実現サービス:寝具の用意や電気設備などあって当然の必要不可欠なサービス
強化サービス:宿泊場所から見れる素晴らしい景色など付加価値的なサービス。

□サービスマネジメント
スタッフの能力、資金などのリソースを適切に組み合わせて顧客にサービスの提供で価値を提供する。
機能とプロセスの管理を行う

 ・サービスマネジメントにおける利害関係者
顧客：サービスにお金を払う人　NS
ユーザ：サービスを実際に利用する人 営業　お客様
サービスプロバイダ：サービスを提供する人　システム部
　タイプ１サービスプロバイダ：事業部門に内在する内部サービスプロバイダ
→部門内のニーズを濃く反映させたサービス提供を行うことができる
　タイプ２サービスプロバイダ：複数の事業部門に強雨湯ITサービスを提供する内部サービスプロバイダ（シェアードサービス部門）　システム部
→分割損を無くす為に作られる
　タイプ３サービス・プロバイダ：外部顧客にITサービスを提供するサービスプロバイダ
IBMの企業のIT部門を担う事業戦略がタイプ３のサービスプロバイダに

教科書の問題疑問点
シェアードサービス部門は内部サービスプロバイダに限定されるのか？外部もあり得るのではないか？？

□機能の概念
機能とは

プロセスや活動を実施する人、およびそれに関与するツールのこと。専門組織
ex)サービスデスク　技術管理　アプリケーション管理　IT運用管理

□プロセスの概念
プロセスとは
特定の達成目標を実現するための一連の活動。
インプットからアウトプットを生み出す為に必要な役割・責任・手段を含む場合がある

プロセスモデルとは
プロセスの構成要素、活動を表現したモデル
→プロセスの特徴を理解、説明するときに使用できる

プロセスモデル↓


①プロセス
インプットを元にアウトプットを行う為の、過程。
活動・手順・役割・改善・測定基準・作業指示書で構成される

②プロセスコントロール
プロセスのアウトプットを確実に提供する為の要素
方針・プロセスオーナ・達成目標・文書化・フィードバックで構成される

③プロセス実現要因
プロセスを実現する要素
リソース・能力で構成される
リソース：ITインフラストラクチャ　ITスタッフ　資金　有形資産
能力：マネジメント力　ナレッジetc 無形資産

※プロセスは自身が生み出したアウトプットの評価をもとに、プロセス改善を行うことから閉ループシステムと呼ばれる


□プロセスの特性

プロセスの特性は４つある
測定可能性
プロセスは適切な方法で測定が可能。(プロセスの効率性を評価する為に)
ex)サービスデスクであればインシデントの発生件数辺り、サービスデスク解決件数など

特定の結果
プロセスは特定の結果を実現する為に存在している。その結果は識別可能で数えられる必要がある

顧客
どのプロセスも主な結果を顧客などの利害関係者に提供する

特定のトリガへの応答性
プロセスは特定のトリガに反応して実行される
ex)インシデント管理では監視ツールのアラートや顧客からの電話がトリガ

□役割の概念
役割とは
個人やチームに与えられた責任、活動、職権。
プロセスや機能の中で定義され、一個人/チームで複数の役割を与えることができる
→高い能力を発揮する為に明確な役割が必要

RACIモデル
役割と責任を定義する為に使用されるモデル
Resoponsible(実行責任者) 　業務の遂行に責任を持つ人
Accountable(説明責任者)　  個々の活動の説明責任者　１人のみ
Consulted(協議先)　　　　   相談を受け、意見を求められる人物
Informed(報告先)　　　　    進捗状況についての最新情報を常に受け取る人物
→場当たり的に決めるのではなく、事前に明確にしておく

プロセスオーナ
プロセスが目的に適しているようにすることに説明責任を負う。
《責任の範囲》
プロセスを評価する為にKPIに対する後援、設計、変更管理、継続改善

プロセスマネージャ
プロセスの運用管理に責任を負う。
《責任の範囲》
プロセスの実行・モニタリング・報告に必要なすべての活動の計画立案と調整

プロセス実務者
１つ以上のプロセス活動を実施することに責任を負う。

サービスオーナ
担当するサービスの開始、移行、保守、サポートについて実行責任を負う。

□サービスライフサイクル
サービスライフサイクルとは
ITサービスマネジメントに対するアプローチの一つ


サービスライフサイクルの構成要素
サービス戦略
事業部門が望む成果の実現や競合他者に対して優れたサービス提供をする為のサービス・プロセスの設計、導入、運用の戦略策定をすること

サービス設計
サービスやサービスマネジメントのプロセスを設計、開発すること

サービス移行
新規、変更されたサービスを運用へ移行させること。移行させる能力の育成と改善

サービス運用
顧客と合意したSLAでITサービスを提供できるようにすること。

継続的サービス改善
顧客のニーズは日々変化する為、常にサービスの効率性・有効性を改善し顧客への価値を創出すること