- 投稿者
- NoB
ITIL V3 Foundation
・サービスストラテジ
財務管理
重要管理
サービスポートフォリオ管理
・サービスデザイン
サービスカタログ管理
サービスレベル管理
キャパシティ管理
ITサービス継続性管理
可用性管理
セキュリティ管理
サプライヤ管理
・サービストランジション
変更管理
ナレッジ管理
リリース管理および展開管理
サービス資産管理および構成管理
・サービスオペレーション
イベント管理
インシデント管理
要求実現
問題管理
アクセス管理
サービスデスク
技術管理
アプリケーション管理
IT運用管理
・継続的サービス改善
継続的サービス改善モデル
7ステップの改善プロセス
- 作成日
- 10/05/21 00:23:19
- 更新日
- 10/06/29 22:31:50
- 大カテゴリ
- 学び
- 小カテゴリ
- 資格
- アクセス数
- 1036
- コメント数
- 2
- お気に入り数
- 6
- コピー数
- 5
- オリジナル
- 無し
- ITIL V3
英国商務局（OGC : Office of Government Commerce）が、ITサービス管理・運用規則に関するベストプラクティスを調和的かつ包括的にまとめた一連のガイドブックのこと。ITサービス管理を実行する上での業務プロセスと手法を体系的に標準化したもので、ITに関する社内規則や手順などの設定・見直しを行う際のガイドラインとして活用される。
- サービスストラテジ（Service Strategy）
・ビジネス要求の明確化
・サービス戦略の策定
- 財務管理
ITサービス・プロバイダの予算業務，会計業務，課金に対する要件の管理を責務とする機能およびプロセス。
- 予算業務
組織内の支出を予測しコントロールする活動のこと。将来の予算を設定する周期的な予算折衝サイクル（通常は年次）と，現在の予算に対する日々の監視，調整を行う。
- 会計業務
ITサービスの提供にかかる実際のコストを分類，把握する。実際のコストと見積もられたコストを比較して，予算の不一致を管理する。
- 課金
顧客に提供したサービスに関して，顧客に支払を請求すること。
- ビジネスケース
事業の主要な支出項目の正当性を説明するもの。利点・代案・課題・リスク・起こりうる問題などに関する情報を含む。
- サービスポートフォリオ管理
サービス・ポートフォリオの管理を責務とするプロセス。
ITサービスが提供する事業上の価値の点からITサービスを検討する。
- サービス・ポートフォリオ
ITサービス・プロバイダによって管理されているすべてのITサービスのこと。
ITサービスのライフサイクルの管理に使用される。
- サービス・パイプライン（検討中，開発中のITサービス）
検討中，開発中で，まだ顧客に提供できない，全てのITサービスの情報を格納するデータベースや文書のこと。
- 要件・定義済・分析済・承認済
- サービス・カタログ（稼働中のITサービス顧客，ユーザに公開される）
稼働中のすべてのITサービスに関する情報を格納するデータベースや文書のこと。
- 制定済・設計済・開発済・構築済・テスト・リリース済・運用中
- 廃止されるサービス
ITサービスを稼働環境から取り除くこと。
- 廃止済
- 需要管理
ITサービスに対する顧客の需要を判断し，その需要にキャパシティが十分対応できるようにする。
- 事業活動パターン（PBA：Pattern of Business Activity）
事業活動の作業負荷の様子。
事業活動パターンは，ITサービス・プロバイダが事業活動を理解し，ITサービスの計画立案に使用される。
- ユーザ・プロファイル
ITサービスに対するユーザの要望のパターン。
- サービス資産
ITサービス・プロバイダがITサービスという形で顧客に価値を提供するために所有している「リソース」と「能力」のこと。
- リソース（お金をかければ調達できるもの）
ITサービスを提供するために必要なITインフラストラクチャ，人材，アプリケーション，情報，資金などの資金のこと。
- 能力（お金をかけてもすぐには調達できないもの）
ITサービスを提供するために必要な人材，ナレッジ，組織，プロセス，管理などの無形の資産のこと。
- 価値
「価値」=「有用性」+「保証」
- 有用性
特定のニーズを満たすために，製品またはITサービスによって提供される機能のこと。
- 保証
顧客がITサービスを使用するのに，十分なキャパシティ，可用性，継続性，セキュリティが提供されること。
- サービスデザイン（Service Design）
・サービスの設計
・可用性，キャパシティ等の決定
- サービスカタログ管理
（顧客に提供するITサービスをサービス・カタログにまとめる）
- ビジネスサービスカタログ
顧客に提供されるITサービスの詳細をまとめたサービス・カタログ。顧客が内容を確認するので，事業部門の担当者が理解できる用語を使用して記述する。
- 技術サービスカタログ
事業部門にITサービスを提供するために必要となる，すべてのサービス（支援サービス）をまとめたサービス・カタログ。通常，技術サービス・カタログは顧客に公開しないため，技術用語を使用して記述します。
- サービスレベル管理
（サービス・カタログ管理でサービス・カタログに
まとめているITサービス=SLAについて，顧客と合意する）
- SLA（Service Level Agreement）
- サービスレベル目標の合意・文書化
- サービスベースのSLA
サービスごとに決まったSLAをあらかじめ用意しておき，サービスごとのSLAを顧客と交わすこと。顧客にとってもプロバイダにとっても非常にわかりやすく安定したサービスを提供することが可能になる。
- 顧客ベースのSLA
顧客ごとに1つのSLAを交わすこと。顧客の独自性を反映したSLAを作成することができるので，顧客に受け入れられやすい。
- マルチレベルSLA
SLAの頻繁な更新を避けるため、企業レベル、顧客レベル、サービスレベルの3体系を分けることにより使いやすいサイズに維持することを可能としたSLA。企業レベルでは、ほとんど更新されることのない基本コンセプトをSLAとして定義。顧客レベルでは、特定の顧客に対するサービス内容について合意。サービスレベルでは、特定の顧客に対する特定のサービスの内容について合意する。
- キャパシティ管理
費用を最小限に抑えつつ，ビジネスのニーズを満たすのに十分なキャパシティが提供されるようにすること。
- 事業キャパシティ管理（ビジネスキャパシティ管理）
ビジネスのニーズと将来の事業計画を把握し，将来，必要になるキャパシティを適切な時期に計画，実装する。
- サービスキャパシティ管理
ITサービスのパフォーマンスとキャパシティを把握することを責務とする。
キャパシティ計画で使用するために，各ITサービスで使用されるリソースと，
使用状況を収集，記録，分析する。
- コンポーネントキャパシティ管理
構成アイテム（コンポーネント）のキャパシティ，パフォーマンスを把握することを責務とする。
キャパシティ計画に使用するために，データを収集，記録，分析する。
- 情報セキュリティ管理
情報セキュリティ管理の最終目標は，ITセキュリティと事業セキュリティを整合させること，およびすべてのサービスとサービスマネジメントの活動において，情報セキュリティが効率的に管理されるようにすること。
- 機密性（Confidentiality）
情報を知る権限を持つ人だけ閲覧可能になっている。また情報を知る権限を持つ人にだけ公開されている。
- 完全性（Integrity）
情報が完全かつ正確で，許可されていない修正から保護されていること。
- 可用性（Availability）
必要とするときに，情報を入手および利用可能なこと。また，情報を提供するシステムが攻撃に対して適切に対処し，障害から復旧，または障害を防ぐことができること。
- サプライヤ管理
良質のITサービスを事業部門に途切れることなく提供できるように，サプライヤおよびサプライヤが提供するサービスを管理し，投資に見合う価値を得られるようにする。
- サプライヤ契約データベース
SCD：Supplier Contracts Database
サプライヤ契約のライフサイクル（契約の確立，契約の更新，終了，契約の評価など）を通して，サプライヤの管理に使用するデータベースまたは構造化された文書のこと。
- アウトソーシング
外部組織のリソースを活用し，ITサービスの設計，開発，保守，運用，サポートの一部分を提供する。
- インソーシング
組織内部（社内）の内部リソースを活用し，ITサービスを提供する。
- コソーシング
インソーシングとアウトソーシングを組み合わせて，ITサービスの設計，開発，移行，保守，運用，サポートに必要なリソースを共同で調達する。
- パートナーシップ・マルチソーシング
ITサービスの設計，開発，移行，保守，運用，サポートのために必要不可欠な専門能力や市場機会をお互いに活用するために，複数の組織が戦略的に連携する。2つ以上の組織との間で正式に協定する。
- ビジネス・プロセス・アウトソーシング（BPO：Business Process Outsourcing）
一部のビジネス・プロセスや機能（例：給与計算，コールセンタ）を，コストの安い地域で提供，管理する。
- アプリケーション・サービス供給
アプリケーション・サービス・プロバイダ（ASP），共有コンピュータ・ベースのサービスをネットワークを通じて顧客の組織に提供する。
- ナレッジ・プロセス・アウトソーシング（KPO：Knowledge Process Outspurcing）
アウトソーシングの最新の形態で，ある面でBPOを一歩進めたもの。単なるプロセスの専門能力ではなく，領域別のプロセスと事業の「専門能力」を提供する。
- OLA（Operational Level Agreement）
ITサービス・プロバイダと同じ組織内の別の部署との間で交わされる合意。OLAは，ITサービス・プロバイダによる顧客へのITサービス提供を支援する。OLAは，提供される商品またはサービス，および両者の責任を定義する。
- UC：外部委託契約（Underpinning Contract）
ITサービス・プロバイダとサードパーティ（外部サプライヤ）との間で交わされる契約。サードパーティは，顧客へのITサービス提供を支援する商品またはサービスを提供する。外部委託契約では，SLAに記載された合意済みサービスレベル目標値を満たすために必要な目標値及び責任を定義する。
- 事業継続性管理（BCM：Business Continuity Management）
- 可用性管理
- 拡張版インシデント・ライフサイクル
インシデントのライフサイクルの詳細。検出，診断，修理，復旧，回復の段階がある。
拡張版インシデント・ライフサイクルは，インシデントのインパクトを増大させたすべての要員を把握し，インパクトをコントロール，低減させる方法を計画するときに使用する。
- 可用性（Availability）
サービス・コンポーネント，構成アイテムが，必要な時に，合意された機能を実行する能力のこと。
可用性（%）=（合意済みサービス時間-停止時間）/合意済みサービス時間×100%
- 信頼性（MTBSI・MTBF）
サービス・コンポーネント，構成アイテムが中断せずにどれだけ長く合意された機能を実行できるかを示す指標のこと。
MTBSI：平均サービス・インシデント間隔（時間）=使用可能な時間/サービス中断回数
MTBF：平均故障間隔（時間）=（使用可能な時間-総停止時間）/サービス中断回数
- 保守性（MTRS）
障害発生後，サービス，コンポーネント，構成アイテムが迅速かつ効果的に稼働状態に回復できるかを示す指標のこと。
MTRS：平均サービス回復時間（時間）=総停止時間/サービス中断回数
- サービス性
サプライヤとの契約時に，支援サービス，構成アイテムの信頼性（MTBF），保守性（MTRS），可用性（Availability）の合意済みのレベルを契約条件に記載します。サプライヤがどの程度この契約条件を満たす能力を持っているかを「サービス性」と呼びます。
- 重要ビジネス要件（VBF：Vital Business Function）
ITサービスによって支えられているビジネス・プロセスの事業上重要な（=欠かすことのできない）要素を表したもの。
- ITサービス継続性管理
ITサービス継続性管理の目標は，災害や事故などの非常時に，SLAで合意された時間内でITサービスを復旧できるようにすること。
- ビジネス・インパクト分析（BIA：Business Inpact Analysis）
ビジネス・インパクト分析の目的は，サービスが中断することによる，事業へのインパクトを定量化すること。
- 復旧オプション
サービスの中断に対応するための戦略。
- ①手作業のワークアラウンド
ITサービスが再開するまでの2～3日間，一時的な措置としてITを使わずに手作業でビジネスが回るようにするということ。
- ③段階的復旧（コールドスタンバイ）
復旧用に「場所」だけを用意しておき，非常時には機器を持ちこんでシステムを再開する方法です。機器を設置する時間が必要になるため，迅速に復旧しなければならないITサービスには適用できません。
- ④間的復旧（ウォームスタンバイ）
復旧用に「場所」と「機器」だけを用意しておき，非常時にはデータのバックアップから復旧することでシステムを再開する方法です。ITサービスを再開するまでに，アプリケーションやデータをリストアする時間が必要になります。
- ⑤高速復旧（ホットスタンバイ）
復旧用に「場所」と「機器」と「データ」だけを用意しておき，非常時にはデータの同期をとることでシステムを再開する方法です。稼働中のシステムと待機しているシステムが定期的にデータの同期をとることで，障害発生時には速やかにITサービスを提供できます。
- ⑥即時復旧（ホットスタンバイ）
復旧用に「場所」と「機器」と「データ」と「サービス」を用意します。常にデータとシステムの同期がとれているバックアップセンタ（場所）を用意し，非常時には即座にサービスの回復を実現するというものです。
- ②相互協定
類似の技術を使用する組織同士が合意し，非常時に助け合う方法。
- リスク・アセスメント
事業を推進するために必要となる資産の価値を分析して，資産に対する脅威を識別し，脅威に対する資産の脆弱性を評価すること。
リスク・アセスメントはリスクを評価し，リスクを許容できるかどうか決定すること。
- リスク低減手段
リスクを評価し，事業および／あるいはITサービスの復旧に対する潜在的な要件を低減すること。
- サービスデザイン・パッケージ
ITサービスとその要件のすべての側面について，
ライフサイクルの各段階を通じて定義する文書のこと。
- サービスデザインツール
サービスや関連するコンポーネントの設計を支援するツール。ハードウェア,ソフトウェア,環境,プロセス,データなどを設計できる。
- 標準と規約の遵守の徹底
サービスデザインツールを導入することによって，設計の迅速化，標準と規約の遵守などの利点が得られる。
- 4つのP
「4つのP」は，それぞれ以下の用語の頭文字です。これらをバランス良く配置し運用していくことが大切であるとし，「4つのP」と呼んでいます。
- 人材（People）
スタッフの能力やスキル
- プロダクト（Products）
サービス，使用するツール（管理システム），技術など
- パートナ（Partners）
サービスを提供するときに利用するメーカ，ベンダ，サプライヤなど
- プロセス（Processes）
サービス設計時の役割，活動。
- サービスデザイン5つの側面
サービスデザインでの設計対象のこと。サービスの設計だけでなく，測定方法と測定基準（何をどのように測定するか）なども合わせて設計する。
- サービス・ソリューションの設計
必要とされ合意された機能要件，リリース，および能力を含むサービス・ソリューションの設計。
- プロセスの設計
サービスの設計，移行，運用，および改善に必要なプロセスの設計。
- 測定方法と測定基準の設計
サービス，アーキテクチャとその構成コンポーネントおよびプロセスのための測定の仕組み，測定方法，および測定基準の設計。
- 技術アーキテクチャの設計
サービスの提供に必要な技術アーキテクチャ（technology architecture）と管理アーキテクチャおよびツールの設計。
- 支援的な仕組みの設計
サービスマネジメントの仕組みとツールの設計，特にサービスライフサイクル全期間を通した管理とコントロールのためのサービス・ポートフォリオ。
- サービストランジション（Service Transition）
・サービス使用テスト
・実運用環境の整備
・リリースと展開
- 移行の計画立案およびサポート
サービストランジションに含まれるすべてのプロセスの計画立案と，必要なリソースを調整するプロセスです。移行の計画立案およびサポートでは，ITサービスの中断のリスクについても識別，管理，コントロールします。
- リリース管理および展開管理
リリースとパッケージ化，構築，テストして本番環境にサービスを導入し，サービスオペレーションへ引き継ぎ，顧客に価値を提供する。
- リリース・パッケージ
同時にリリースするためにパッケージ化されたリリース・ユニット全体のこと。単一のリリース・ユニットの場合や複数のリリース・ユニットのセットで構成される場合がある。
- リリース・ユニット
通常，同時にリリースされるサービス，ITインフラストラクチャの一部分。構成ユニットをまとめたリリースする単位。
- リリース
ITサービスに対する許可された変更の集合体。
- ビックバンアプローチ
新規サービスやサービス変更を一斉に展開すること。
- 段階的アプローチ
新規サービスやサービス変更を一部のユーザに限定して展開する方法のこと。その後，他のユーザにも同じ変更を繰り返し展開する。
- プッシュ・アプローチ
中央拠点から配信先へと配信される（プッシュされる）展開方法。
- プル・アプローチ
ユーザが選択した時点またはユーザのPCやサーバの起動時に，中央拠点から持ってくる（プルする）展開方法。
- 自動
新規サービスやサービスの変更を自動で配信すること。
- 手動
新規サービスやサービスの変更を手動で配信すること。
- サービス資産管理および構成管理
- DML（Definitive Media Library）
承認済のバージョンのソフトウェア，文書のマスターコピーを保管し，保護する1つまたは複数の場所。このライブラリには社内で開発したソフトウェア，ベンダから購入したソフトウェアの両方が含まれる。
- セキュアストア
- サービス・ナレッジ管理システム（SKMS：Service Knowledge Management System）
ナレッジ，情報の管理に使用される一連のツール，データベースのこと。
- 構成管理システム（CMS）
ITサービス・プロバイダの構成データの管理に使用される，一連のツール，データベースのこと。
- 構成管理データベース（CMDB）
構成アイテムを管理するデータベースのこと。CIの属性，他のCIとの関係を保存する。
- 構成アイテム（CI）
ITサービスの提供のために管理する必要がある，あらゆるコンポーネントのこと。一般に，ITサービス，ハードウェア，ソフトウェア，スタッフ，SLAなどの正式文書などを含む。
- 構成識別
構成アイテム及びそれらの関係に関する情報を収集し，構成管理データベースに格納することを責務とする活動。また，構成アイテム自体にラベル付けすることも責務とする。
- 構成コントロール
変更要求やサービス要求の提出などにより，CIの追加，修正，削除が適切に管理されるようにすることを責務とする活動。
- ステータスの説明と報告
構成アイテムのライフサイクルを記録，報告することを責務とする活動。
- 構成ベースライン
正式に合意済みで，変更管理プロセスで管理される構成のベースライン。構成ベースラインは，将来の構成，リリース，変更のベースとして使用される。
- 変更管理
変更管理の目的は，標準化された手順，手法を用いて，あらゆる変更を効率的かつ迅速に処理すること，事業にもたらされるリスクを最適化すること。
- 変更要求（RFC：Request For Change）
サービス変更の要求，提案のこと。RFCには，変更の詳細が記述される。
- 変更管理の7つのR
変更を評価，アセスメントするときの7つの重要な質問のこと。
この7つの質問に答えることによって，変更に失敗したときのビジネス（事業部門）へのインパクト（影響度）を確認することができます。
- ①Raised（変更を提起したのは誰か？）
- ②Reason（変更の理由なは何か？）
- ③Return（変更からどんな見返りがあるか？）
- ④Risk（変更によって，どんなリスクが考えられるか？）
- ⑤Resource（変更の実施には，どんなリソースが必要か？）
- ⑥Responsible（変更の構築，テスト，実施における責任者は誰か？）
- ⑦Relationship（この変更と他の変更の間には，どんな関係があるか？）
- 変更（サービス変更）
許可，計画，サポートされているサービスやサービスの構成要素（サービス・コンポーネント）とその関連文書を追加，修正，削除すること。
- 変更諮問委員会（CAB：Change Advisory Board）
変更を許可し，変更の評価および優先度決定において変更管理を支援するための機関。変更マネージャが議長を務め，変更による利害関係者（顧客，ユーザ，サービスデスク，運用スタッフ，サプライヤなど）で構成される。
- 変更スケジュール
承認済みのすべての変更の詳細と変更の実施予定日をまとめた文書のこと。「将来的な変更スケジュール」と呼ばれることもあるが，実施済みの変更に関する情報も含む。
- 変更モデル
変更のインパクト，大きさなどによる分類のこと。「通常の変更」，「標準的な変更」，「緊急の変更」がある。
- 通常変更
通常の変更手順に従って行う変更のことです。変更が発生するたびに，RFCを起票し，変更マネージャが承認を行います。承認にあたっては，変更諮問委員会（CAB）が助言します。
- 標準的な変更
ビジネスへの影響度，リスク，コストが少なく，変更管理によって手順が確立された（手順が承認済の）変更のことです。つまり，「標準的な変更」ではきめられた手順以外の変更は行いません。また，サービスデスクなどに権限を付与しておき，変更のたびに変更マネージャが承認することはありません。
- 緊急の変更
ビジネスに大きな影響を与えており，早急に変更しなければならない変更のことです。通常，ITサービスの障害を復旧する場合にだけ使用します。
- 変更マネージャ
すべてのRFCについて，受領，登録を行い，優先度を割り当て，必要なメンバーを招集し，RFCのクローズ（すべての処置の終了）まで責任を持つ人。
- 緊急変更諮問委員会（ECAB：Emergency Change Advisory Board）
緊急の変更が必要になった場合（CAB全体を招集する時間的余裕がない場合）に召集される，緊急の意思決定を下す権限を持つCABより小規模なグループ。
- サービスの妥当性確認およびテスト
新規ITサービスやITサービスの変更が，ビジネスの要件にあっているか，サービスデザインの設計どおりになっているかをテストし，品質を保証するプロセスです。
- サービスVモデル
サービスを構築，テストするときに行うべき5つの構成レベル。事業部門と合意した要件に達するまで，様々な構成レベルを通してサービスを構築・テストする方法を示す。
- データ-情報-知識-知恵（DIKW）
DIKW:Data-to-Information-to-Knowledge-to-Wisdom
データ，情報，知識，知恵の間の関連を理解する方法。
「データ」は，個別の事実であり，整理されていない単なる事実のことです。
「情報」は，「データ」を整理したものです。
「知識」は，「情報」を分析してわかる傾向のことです。
「知恵」は，いくつかの「知識」をもとに意思決定する際の「人間の知恵」のことです。
- 評価
- サービスオペレーション（Service Operation）
・サービスの提供
・モニタリング
・ユーザサポート
・要求管理
- イベント管理
ライフサイクルを通してイベントを管理する。イベントを検出して把握し，適切な対応を決定する。
- イベント
構成アイテムやITサービスの管理にとって重要性のある状態の変更。
- 情報
どのような対処も不要なイベントのことです。
- 警告
何らかの理由により現在の状態に注意を払う必要があるイベントです。
- 例外
- アラート
しきい値に達したとき，変更があったとき，または障害が発生したときの警告。人に対して通知され，人の介入を必要とする。
- インシデント管理
正常なサービス運用を可能な限り迅速に回復し事業への悪影響を最小化すること。
- インシデント
ITサービスの計画外の停止や品質低下のこと。
- インシデント・モデル
インシデントが発生したときに実施する，事前に定義した処置の方法のこと。
- 重大なインシデント
事業に深刻な中断を与える原因となるインシデントのこと。
- 緊急度
事業にとってどれだけ早く解決する必要があるか。
- インパクト
インシデント，問題，変更によるビジネスに与える影響の指標。
- 優先度
インシデント，問題，または変更の対象的な重要度の識別に使用されるカテゴリ。優先度はインパクトと緊急度に基づいており，行うべき処置に必要な時間の特定に使用される。「優先度」=「インパクト」+「緊急度」
- エスカレーション
インシデントをタイミング良く解決するための支援をする仕組み。機能的エスカレーションと階層的エスカレーションがある。
- 1次サポート，2次サポート，3次サポート
1次サポート：サービスデスク
2次サポート，3次サポート：インシデントを解決するためのより高度な専門スキル，より多くの時間，あるいはリソースを所有しているサービスデスク以外の部門と（専門家）サポート・グループ。
- 要求実現
サービス要求（情報や助言，または標準的な変更やITサービスへのアクセスに対するユーザからの要求）を合意された手順に従って処理することで，顧客やユーザのサービス要求を支援する。
- サービス要求
情報や助言，または，標準的な変更やITサービスへのアクセスに対するユーザからの要求のこと。例えば，パスワードのリセットや，新しいユーザに対する標準的なITサービスの提供など。通常，サービス要求はサービスデスクが処理し，RFCの提供は要求されない。
- 要求モデル
「サービス要求」を処理する事前に定義した処理方法のこと。
- セルフヘルプ
サービス要求，インシデントの登録やFAQの参照など，ユーザ自らがサービスデスクを利用できるようにする仕組みのこと。
- 問題管理
問題とその結果発生するインシデントを防止する。また再発するインシデントを取り除き，防止できないインシデントのインパクトを最小限に抑える。
- 問題
1つまたは複数のインシデントを引き起こす道の原因。
- 問題モデル
問題が発生したときに実施する事前に定義した処置のこと。
- ワークアラウンド（回避策）
問題に対する回避策。
- 既知のエラー
診断が成功しワークアラウンド（回避策）が識別された問題。（対応策が特定されているインシデント）
- 既知のエラーデータベース（KEDB）
すべての既知のエラー・レコードを含むデータベース。サービスナレッジ管理システムに含まれます。
- リアクティブな問題管理
イベントが発生してから，その原因についての調査，分析を行います。根本的な原因を突き止めることで，再発を防止することを目的とする活動を行います。
- プロアクティブな問題管理
将来，発生する可能性のある問題を予防する活動。
- アクセス管理
許可されたユーザにサービスを利用する権利を与え，許可されていないユーザに対してはアクセスを制限するプロセス。アクセス管理が「だれがどのサービスにアクセスできるかを決定するのではない」という点に注意。誰がどのサービスにアクセスできるか決定するのは，サービスデザインの「情報セキュリティ管理」「可用性管理」です。アクセス管理は，「情報セキュリティ管理」「可用性管理」で決定した方針，規則をもとにITサービスを利用する権限をユーザに割り当てます。
- アクセス
ユーザが利用する資格を持つサービスの機能やデータのレベル／範囲のこと。
- ID
ユーザを個人として識別する情報。ユーザのIDはユーザごとに一意の物。
- 権限
サービスやサービス群へのアクセスをユーザに提供する実際の設定のこと。一般的な権限には，読み取り，書き込み，実行，変更，削除などがある。
- サービス群
複数のサービスをグループ化したもの。利用可能な複数のサービスへのアクセスを，ユーザやユーザグループに付与することで効率化を図ることができる。
- ディレクトリ・サービス
アクセスや権限を管理するためのツール。
- サービスデスク
ITサービスプロバイダとユーザ間における日常の単一窓口である。また，ユーザが抱えるすべての問題（インシデント，サービス要求，標準変更）を受ける窓口でもある。
- 単一窓口（SPOC）
事業部門からみたITサービス・プロバイダへの単一の連絡手段のこと。
- IT組織全体の調整
円滑なコミュニケーションを維持しつつ，ユーザの利益になるよう，ITサービス・プロバイダ（各組織，プロセス）の活動を調査する。
- ローカル・サービスデスク
ユーザの拠点内に設置されたサービスデスクであり，オンサイト対応が可能である。
- 中央サービスデスク
複数の拠点の窓口を集約したサービスデスク。
- バーチャル・サービスデスク
実際の拠点は分散しているが，疑似的に1つのサービスデスク機能を提供する。
- フォロー・ザ・サン
24時間365日，サービスを提供するために，世界中のサービスデスク，サポート・グループを活用する。
- インシデントのオーナーシップ
受け付けたインシデントに対してクローズするまでインシデント活動を追跡し，必要に応じてフォローを行う。
- ユーザおよびITスタッフとのコミュニケーション
インシデントを円滑に解決に導くために，ユーザや必要な部門と接点を持つこと。
- 進捗状況の提供
調査に時間を要するインシデントなどに対して，ユーザに途中経過などを報告すること。
- 管理情報の提供
インシデントをさまざまな分類から統計，解析し，サポートデスクの運用の向上に役立てる。
- 技術管理
ITインフラストラクチャの運用管理に必要な技術力，リソースを提供する。ITサービスの設計，テスト，運用，改善も支援する。
・ITインフラストラクチャの設計
・ITインフラストラクチャの保守
・障害発生時のサポート
- アプリケーション管理
アプリケーションのライフサイクル（要件の収集，設計，構築，展開，運用，最適化）を通して，アプリケーションの管理に責任を負い運用中のアプリケーションの管理とサポートを担当する。また，ITサービスの一部をなすアプリケーションの設計，テスト，改善に重要な役割を果たす。
・アプリケーションの設計
・機能の可用性の保証
・アプリケーションの保守
・障害発生時のサポート
- IT運用管理
ジョブのスケジュール，バックアップ，リストアなど，日常的な運用活動の実施に責任を負う。
- 運用コントロール
ITサービスとITインフラストラクチャのモニタリングとコントロールを責務とする機能。ジョブのスケジューリング，ネットワーク運用センタでネットワークを監視するなど，日常の運用管理活動を実施します。
- 施設管理
サーバ室，データセンタなどの電力や空調設備のような，物理的なIT環境を管理します。
- 継続的サービス改善（Continual Service Improvement）
・測定
・評価
・サービスのレポート
・改善計画
- 7ステップの改善プロセス
継続的サービス改善でデータを測定して分析するプロセス。
- ①測定すべきものの定義
事業部門(顧客)とITサービス・プロバイダ間で，何を測定すべきか協議し，測定対象を決定します。
- ②測定できるものの定義
「①測定対象の定義」で洗い出した項目から，どの項目が実際に測定可能か検討します。要員，体制，ツールの機能，業務手順などの制約を考慮し，測定可能な内容を決定します。
- ③データの収集
「②測定できる内容の定義」で決定した測定多少を誰がいつ，どのように，どれくらいの頻度で収集するかなど，データ収集のための体制を決定し，データの収集を開始します。
- ④データの処理
収集した「データ」は生データで，このままでは意味を持ちません。この段階では，「データ」を「情報」に変換し，意味を持たせます。「情報」に変換するときには，頻度，形式(表，グラフなど)，精度などを考慮し処理ます。
- ⑤データの分析
データ処理された「情報」をもとに，「目標値を満たしているか?」「目標値を満たしていない場合，原因は何か?」「この問題は是正する必要があるか?」などを分析し「知識」として活用できるようにします。
- ⑥情報の提示と利用
データの分析結果をレポートとしてまとめ，事業部門，経営者，ITサービス・プロバイダといった利害関係者に報告しレビューします。報告，レビューなどを行うことによって，「知識」を「知恵」として利用できるようにします。
- ⑦是正処置の実施
「⑥情報の提示，活用」でレビューした結果，是正措置が必要と判断した場合には，サービスを改善していきます。是正措置が必要と判断しても，組織にすべてのケースで改善できるとは限りません。ビジネス部門の最終目標などに基づいて，優先順位をつけて改善していきます。あまりにも，工数がかかるためあえて改善しない，という選択も十分あり得ます。
- プロセス測定基準
サービスマネジメントのプロセスの有効性や効率性を測る測定基準のこと。（サービスデスクでの解決率，インシデントの平均解決時間など）
- サービス測定基準
エンドツーエンドのサービスの結果のこと。コンポーネントの測定基準を使用し，サービス測定基準を算出する。（ITサービスの稼働率など）
- デミングサイクル
品質改善で用いられる4つの段階（計画，実施，点検，処置）を持つサイクルのこと。
- 継続的サービス改善モデル
継続的サービス改善で使用するデミング・サイクルのモデル。
- ①ビジョンは何か
ビジネスの達成目標を理解し，ビジョンを認識します。
- ②現状はどこにいるのか？
現状を分析します。
- ③どこを目指すのか？
達成すべき目標を設定します。また測定方法を決定します。
- ④どのように目標を達成するか?
目標達成のために何をしなければならないかを決定します。
- ⑤目標の達成をどのように確認するか?
目標の達成を評価します。
- ⑥どのようにして推進力を維持するか?
品質改善の推進力（モチベーション）を維持し，繰り返し改善します。
- ベースライン
基準点として使用するベンチマークのこと。改善後の測定の結果との比較作業で使用する。
- 測定する理由
- 技術測定基準
可用性やパフォーマンスなどといった，ITサービスを構成するコンポーネントやアプリケーションの測定基準のこと。（CPU使用率，メモリ使用量など）
- プロセスの特性
プロセスには，測定可能，具体的な結果を伴う，利害関係者への結果の提供，特定のイベントに対応という4つの特性がある。
- ①測定可能
プロセスは適切な方法で測定できます。
測定結果は，主にプロセスが効率的に運用できているかなどを判断するときに使用します。
- ②具体的な結果を伴う
プロセスは具体的な結果を実現するために存在しています。結果は個別に識別可能で，数えられる必要があります。
- ③利害関係者への結果の提供
どのプロセスも，その主な結果を顧客又は，利害関係者に提供します。顧客または利害関係者は，組織の内部にいる場合も外部にいる場合もありますが，どちらの場合も，顧客，利害関係者の期待を満たす必要があります。
- ④特定のイベントに対応
プロセスは特定のイベントに反応して実行されます。プロセスを開始させるイベントをトリガーといいます。「特定のイベントに対応する」は，プロセスを開始させるトリガーを明確に突き止められることを意味しています。
- RACIモデル
役割と責任を定義するために使用されるモデル
- Responsible実行責任者
業務の遂行に責任を持つ人物（1人または複数）
- Accountable説明責任者
個々の活動の説明責任者（1人のみ）=プロセス・オーナ
- Consulted協議先
相談を受け，意見を求められる人物（複数）
- Informed報告先
進捗状況についての最新情報を常に受け取る人物（複数）