利害関係者用語 組織が果たす役割 サービスプロバイダとサービス消費者が同一(内部組織、内部サービスプロバイダ) 異なる場合(外部組織、外部サービスプロパイダ)

利害関係者用語 サービスに組み込まれている「サービス、機材、資材」を提供する組織

利害関係者用語 顧客、ユーザ、スポンサー サービスプロバイダにフィードバックするなど協力し合う必要がある 各役割は状況によって変わり、兼務することもある

サービス消費者 サービスの要件を定義し、サービスを消費した成果に対して責任を負う役割

サービス消費者 サービスを利用する役割

サービス消費者 サービス消費の予算を承認する役割

定義は広く 登場人物は全て利害関係者

【業界周辺用語】 顧客が特定のコストやリスクを管理することなく、望んでいる成果を得られるようにすることで価値の共創を可能にする手段

【業界周辺用語】 顧客にとっての価値をサービスの形で実現する、組織の専門能力の集まり＝能力である

【業界周辺用語】 認識されている便益、便利さ、および何らかの重要性のこと 認識されていなければそれは勝ちにはならない

【業界周辺用語】 1つまたは複数のアウトプットによって可能になる、利害関係者にとっての結果 ・成果を促進することで価値になる ・価値は受け取り手によって異なる

【業界周辺用語】 活動の有形、または無形の提供物のこと 形が無いこともある

【業界周辺用語】 特定の活動、またはリソースに費やされた金銭の額 時間

【業界周辺用語】 損害や損失を引き起こす、または目標達成の実現をより困難にする可能性のあるイベント 起こるか起こらないかわからないこと

こいつらは 取り除かれるものと課されるものの2つある マイナスの効果よりプラスの効果が大きい時にのみ価値がつく

有用性と全ての保証を兼ね備えることで価値に繋がる

【価値周辺用語】※目的適合性 特定のニーズを満たすために、製品またはサービスによって提供される機能のこと

【価値周辺用語】使用適合性 製品またはサービスが合意済みの要件を満たすことに対する確約 4つのうちどれも欠けてはいけない 全てを満たしている必要ですがある 可用性、キャパシティ、セキュリティ、継続性

リソースを組み合わせることで製品になり、製品の一部を組み合わせることで顧客のニーズに応じたサービス提供物にする

【サービス周辺用語】 サービスを提供するために使うもの ヒト、モノ、カネ、情報

【サービス周辺用語】 サービス消費者に価値を提供するために設計された組織のリソースの構成 ※作られた製品がすべてサービス提供のために利用される訳では無い

【サービス周辺用語】 1つまたは複数のサービスについての形式的な説明 ※製品の組み合わせ、サービス消費者のニーズを満たした組み合わせ大切 商品、リソースへのアクセス、サービス活動の3つ

【サービス周辺用語】 サービス提供物 有形リソース 所有権が移ると権限と責任も同時に移管する

【サービス周辺用語】 サービス提供物 サービス・プロバイダがサービス消費者にリソースへのアクセスを許可すること リソースそのものの所有権はサービス・プロパイダが持ち続ける

【サービス周辺用語】 サービス提供物 サービス消費者のニーズに合わせて実行される活動のこと

包括的なアプローチを支援するためのサービスマネジメントの4つの側面 これは全てのものを1つと捉える その全てを検討する必要がある 【4つ】 組織と人材 情報と技術 パートナとサプライヤ バリューストリームとプロセス

サイロをいかに突崩すかが大切 組織間の関係性を重要視 ①正式な組織構造 ②カルチャ ③必要なスタッフの配置とコンピテンシ ④役割と実行責任

人々の集団が共有している一連の価値観 変えるためには「行動」を変える必要がある

個人のスキルや行動特性のこと

①情報とナレッジ ②技術 ③コンポーネント間の関係

情報セキュリティの考慮が含まれる

サービスマネジメントを支援する技術とITサービス自体を支援する技術の2種類ある 技術選択においてビジネスの面とカルチャの面が影響する

構成要素

①パートナとサプライヤ戦略 ▶企業のカルチャに気をつけて ②契約の管理 ③サプライヤ間のコラボレーションの促進

この2つによってサービス消費者と合意済みの達成目標を実現するために必要な「活動、ワークフロー、コントロール及び手順」を定義

需要＆機会から価値までのエンドツーエンド 需要＆機会をインプット 価値をアウトプット

その中のタスクの順番や手順を定義

【目的地】 全ての利害関係者と協力し、継続的に価値を共創できるようにすること 各サービス・プロパイダにひとつしかない 固定的ではなく柔軟性抜群 【構成要素】 従うべき原則 ガバナンス バリューチェーン プラクティス 継続的改善

最終目標、戦略、業務の種類、管理構造が変化したとしても、あらゆる状況で組織を導くことができる推奨事項

価値の創出を促進する運用モデル

一連の組織のリソース

繰り返して実行される組織の活動(管理プラクティスにもあり)

▶全ての活動は価値に結びついていないといけない サービス消費者は誰であるかを理解する

▶現状を否定して、全く新しいものを作ることは推奨しない 適用するには？ 進め方の意思決定にはデータ活用が必要 指標は観察対象そのものの代わりにはならない データに頼りすぎると先入観がおきる 客観的にみろ 現状から何も再利用できない場合もある

アジャイル開発の考え方がベース →短期間を1つのサイクルとして開発を進める ▶作業を小さなセクションに分割し、小さな目に見える成果を積み重ねることが大切である 「柔軟性の向上」 「ニーズへの迅速な対応」 「障害の早期発見対応」 が可能になる 適用するには？ ・全体を理解、行動も起こす ・分析麻痺に気をつける →分析ばかりに時間を費やして何も実行しないこと 絶対避けて そもそもフィードバックを受けるには 「実際に使えるもの」をつくる 完全不完全なものをつくるのとは違う

組織のあらゆる活動で利害関係者からフィードバックを受ける仕組みを作る

▶作業やその結果を可視化することが大切であるという原則 適用するには？ ・何かを始める前に全員の合意はいらない ・対象者に合わせた適切なコミュニケーション方法を選択 ・意思決定はデータに基づいて実施する ・リーン開発の考え方をベース ※開発工程でないところも考え方を適用 あらゆる所で可視性を高める

3M(ムリ、ムダ、ムラ)を取り除く サイロを打ち破る

▶活動は包括的に対応することが大切であるという原則 適用するには？ ・システムの複雑さのレベルを認識する 4つの側面でも「包括的なアプローチ」に 基づいた原則ででたね

▶シンプルがキーワード 価値をもたらさないモノは廃止すべきであり、必要なステップ数も最小とするべき 例外だけでなく、全般的に対処する方法を考えるべき コントロールや測定基準は必要な場合のみ追加すべき 適用するには？ ・価値に着目する ・活動の数を最小限に抑えて 質を高めることに集中する ・シンプルは使われる ・シンプルは繰り返せる

▶無計画に自動化するのではなくまずは活動を最適化 これがないことにはかえってコストが増加してデメリットがあるよ →組織の堅牢性と対障害弾力性を失う 適用するには？ ・必ず自動化の前に最適化 ・評価するために価値に重点をおいた測定基準をつくる ・ほかの原則も適用 ※自動化はデメリットもあるよ

従うべき原則は互いに依存関係があり、相互作用がある 全ての原則を同時に適用してゆくことが大切

▶価値の創出を促進する運用モデル 【構成要素】 ①計画 ②改善 ③エンゲージ ④設計および移行 ⑤取得＆構築 ⑥提供およびサポート

▶組織全体で4つの側面全てと全製品および全サービスのビジョン、現状、改善の方向性についての理解を共有すること 計画するだけでなく組織全体に伝える

▶すべてのバリューチェーン活動とサービスマネジメントの4つの側面について、製品およびサービス、プラクティスを継続的に改善すること ※ITILの重要な概念

▶利害関係者のニーズ、すべての利害関係者との継続的なエンゲージ、透明性、およびすべての利害関係者との関係強化について十分な理解を促すことにある ※サービスプロバイダからみて、外部の利害関係者とのやり取りであり、双方向の関係性である

▶製品およびサービスが品質、コスト及び市場投入までの期間について利害関係者からの期待に継続的に応えられるようにすること QCDを考慮したサービスの設計と移行 Q(クオリティ)C(コスト)D(納期)

▶サービス・コンポーネントが合意された仕様を満たし、必要な時と場所で利用できるようにすること ※調達やサービスのコンポーネントの作成である おさらい︰コンポーネント(構成要素)

▶利害関係者の期待に応じて、合意された仕様に従ってサービスの提供およびサポートを実施すること

・計画立案は計画の活動を通じて実行される ・改善は改善の活動を通じて開始され管理される ・外部利害関係者とのやりとりはすべてエンゲージの活動を通じて実行される ・新たなリソースはすべて取得＆構築の活動を通じて獲得される ・作成変更提供メンテナンスサポートは、 設計および移行、取得＆構築、提供およびサポートが調整された形で実行される

▶需要＆機会から価値までのエンドツーエンド(始まりから終わりまで経路全体) ひな型や、固定的な管理プラクティスの組み合わせはないため、 作成後継続的に改善 具体的なシナリオに合わせてプラクティスガイドを参考にサービスバリューストリームをつくる

サービスレベル管理 関係管理 サプライヤ管理 情報セキュリティ管理

目的▶サービスの色々な測定基準とその目標値を顧客のビジネスに基づいて決定 評価、モニタリング、管理ができるようにすること 具体的には？ ①測定基準とその目標値をSLAとして顧客と合意する ②サービスをエンドツーエンド(はじめからおわりまで経路全体)に可視化する

▶サービス品質を定義する1つまたは複数の測定基準 大切なこと3つ ①顧客とのエンゲージで顧客と成果ベースの共通認識を確立する ②測定基準とその目標値を定め、データを集め、分析、保存、報告する ③測定値と目標値が適切なものか見直し続ける

▶必要とされるサービスとサービスで期待されるレベルを規定するための、サービスプロバイダと顧客の間で結ばれる合意文書 作成する上で重要な4つのポイント ①サービスに関連していること →やりやすさでえらばない ②成果に関連していること →定量的だけ❌定性的な指標もバランスよく ③パートナとサプライヤが関与すること ④全ての関係者が理解出来ること

▶SLAが不適切で、SLAを満たしていても顧客が不満を抱いている状態 防ぐには？ 顧客とのエンゲージとフィードバックを大切に

目的▶組織と利害関係者のつながりを確立し深める 具体的には？ 利害関係者のニーズを理解し、苦情に対処し、満足度を維持すること

目的▶サプライヤとそのパフォーマンスを適切に管理すること 具体的には？ サプライヤ戦略や方針、契約の管理をする

目的▶情報を保護すること 5要素 機密性、完全性、可用性、認証、否認防止

変更管理 展開管理 リリース管理 サービス構成管理 IT資産管理

▶変更に伴うマイナスのリスクを評価し、承認とスケジュール管理を行いIT変更の成功する回数を最大化する

▶サービスに直接的または間接的に影響を及ぼす可能性がある何らかの追加、修正、削除 「新規と削除」も変更に入る

①【変更実現の適用範囲(スコープ)】 に何を含めるかは各組織で定義する ②【組織変更の管理との違い】 変更実現は通常、製品及びサービスの変更を対象としていて組織の変更は対象外 ③【変更実施の判断】 変更に伴うマイナスのリスクと期待されるメリットをアセスメント(評価)し、バランスをとる ④【変更の承認】 変更の種類ごとに適切な変更許可委員を割り当てることが重要 ⑤【変更スケジュールの用途】 実施前︰変更の計画立案、連絡の支援、衝突の回避、リソースの割り当て 展開後︰インシデントの管理、問題管理、継続的改善 ⑥【3種類の変更とその特徴】 ▶全ての変更はアセスメント(評価)と承認が必要

①通常の変更 →標準プロセスにしたがってスケジューリング、評価、承認を行う必要がある変更 自動化されたパイプラインを持っている組織はプロセスのほとんどのステップを自動化している場合あり ②標準的な変更 →リスクが低く予め承認された変更 多くの変更は標準的な変更 個別にアセスメントと承認は不要 手順の変更するときにはまた必要になる ③緊急の変更 →可能な限り迅速に実行する必要がある変更 変更スケジュールは含めない アセスメント、承認は必要だけど変更ログの文書化は事後でもいい テストは最小限

▶新規および変更されたハードウェア、ソフトウェア、文書、その他のコンポーネントを稼働環境に移行(移動)すること リリース管理とは異なる

▶新規および変更されたサービスと特性を利用可能な状態にすること 稼働環境に移動する＝展開管理 利用できるようにする＝リリース管理

▶使用可能にしたサービスまたは他の構成アイテムのバージョン、あるいは構成アイテムの集合

▶構成アイテム(CI)に関する正確な情報を利用できるようにすること 具体的には？ ・情報収集だけでなく利用可能にすること ・関連性についての情報も扱うこと ・どのレベルの情報までを管理するかについて検討することが重要

▶ITサービスを提供するために管理する必要がある、あらゆるコンポーネント(部品、成分、要素) CIに経済的価値は無関係

▶あらゆるIT資産の全サイクルを計画して管理すること 具体的には？ ・コストのコントロール、リスクの管理 が実施内容に含まれる ・IT資産と構成アイテムはちがう (IT資産は経済的な価値をもつが、構成アイテムは持たない)

▶経済的な価値を持つすべてのコンポーネント

サービスデスク サービス要求管理 モニタリング管理 インシデント管理 問題管理

▶インシデント解決およびサービス要求の需要を収集する ・サービスプロパイダとユーザの接点 ・問い合わせはインシデントまたはサービス要求のどちらかに分類 ・軽微なインシデントの解決やインシデントの１次対応を実施 【運用方法】 ①サービスデスクは単一窓口であるべき ②自動化は優れたCXにさらに専念するために実施 ③スタッフに必要な3つのスキル ・コミュニケーション能力、心の知能指数(EQ) ・ビジネスに対する理解 ・自分のスキル以外も利用してアクションする能力 ④チャネルの種類 ⑤タイプの種類 ▶ローカルサービスデスク、中央集中型デスク、仮想的なサービスデスクの3つ

▶サービスの計画外の中断、またはサービス品質の低下 ・サービスにとって好ましくない出来事 ・サービス利用できていてもインシデントになる場合あり

▶通常のサービス提供の1部として合意されたサービス活動を開始する、ユーザまたは権限を与えられたユーザ代理人からの要求 ・フィードバック、称賛、苦情が含まれる ・顧客ではない

▶ユーザが開始したすべてのサービス要求を処理し合意済みのサービス品質を支援すること ・明確で標準的なプロセスと手順を使用 ・変更を実施する場合は標準的な変更として実施 ・対応のために承認が必要になる ・ワークフローモデルの数を絞ると効率性保守性が向上する ・自動化はセルフサービス化する方針で検討すべき

▶サービスおよびサービスコンポーネントを体系的にモニタリングし、イベントとして識別された「状態の変更」を選別して記録および報告すること

▶イベントを検出する

▶サービスまたはその他の構成アイテム(CI)を管理するうえで重要な意味を持つ状態の変更 ・サービスに何らかの影響があるもの全てがイベント

▶可能な限り迅速にサービスを通常のサービスオペレーションに回復してインシデントの悪影響を最小限に抑えること 9個 ・目標解決時間をSLAに組み込む ・全てのインシデントはインシデントレコードとして記録されるべき ・インシデントを優先順位付けする目的は、ビジネス上の影響が大きいインシデントから先に解決されるようにするため ・インシデントをカテゴリ分けする目的は、正しいエスカレーション先に割り当てるため ・重大なインシデントや、情報セキュリティインシデントは個別のプロセスを整備すること(臨時チームを組む時も) ・軽微なインシデントはサービスデスクで解決する ・パートナやサプライヤを巻き込むために、サポート契約を結ぼう(コミュニケーションはインシデント管理の1部として実施) ・複雑なインシデントのもろもろ詳細は手順書化できない ・インシデント解決のために災害復旧計画を実行することもある

▶課題や作業項目の情報を共有する またはそのオーナーシップを移管する活動

目的▶インシデントの原因を調査し、原因を解消する方法を見つけること インシデントの数を減らしたり再発した際にすぐに解消できるようにする

分析済みだが未解決の問題

1つまたは複数のインシデントの原因、または潜在的原因

イメージは暫定対応策 ▶まだ完全な解決策がないインシデントまたは問題のインパクトを軽減または排除するソリューション(解決・解答) ・必ず適用条件もセット ・問題レコードに文書化される

①問題の識別と記録 ▶サービスデスクで繰り返し発生する課題を検出する ▶インシデントが再発するリスクを識別する ▶内部の開発者、テストチーム、プロジェクトチームやサプライヤとパートナから得た情報を分析 ②問題のコントロール ・ビジネスへのインパクト、リスクを考慮した優先順位付け→ 優先順位高い順から分析→ 分析はサーマネの4つの側面から ・問題解決できない場合はワークアラウンドが恒久的な対処策になる 問題レコードは既知のエラーのまま残り続ける ③エラーコントロール ▶既知のエラーを定期的にアセスメントする

変更実現、インシデント管理、継続的改善と仲良し

目的▶改善により組織のプラクティスおよびサービスを変化するビジネス・ニーズと整合させること 「改善」とは変化への適応

▶改善のアイデア識別から最終的に取られたアクションまでを追跡し、管理するための管理簿 ・改善案は組織内のあらゆる活動から提案できるが、CIRに文書化することが重要 ・改善案は記録、文書化、評価、優先度付がをする

・継続的改善は組織全員の責務 ・組織全員が全ての業務で改善を意識するには行動とカルチャを変えていく必要がある →行動とカルチャをかえるためには組織上層部のリーダーシップとコミットメントが重要 ・専任で継続的改善を実施するチームが必要である ・サプライヤとの契約内容に継続的改善の活動を含めることが望ましい ・継続的改善の意思決定はデータを根拠にする