4.1 サービスデザインの概要
サービス・デザイン→サービスストラテジで明確にした事業部門の要件をもとにサービス設計する事。
ITサービス設計をする際の考慮点→機能性(ITサービスの機能、品質)リソース(費用、スタッフ)スケジュール(期間)
人材(People)→スタッフの能力やスキルの事。

プロダクト(Products)→サービス、使用するツール(管理システム)技術の事。 
パートナ(Partners)→サービスを提供する時に使用するメーカ、ベンダ、サプライヤの事。
プロセス(Processes)→ サービス設計時の役割、活動の事。
サービスデザインの5つの側面→サービスデザインでの設計 対象の事。サービスソリューション設計、支援的な仕組みの設計、技術アーキテクチャ設計、プロセス設計、測定方法と測定基準の設計。
サービスデザイン7つの構成要素→サービスカタログ管理、サービスレベル管理、キャパシティ管理、可用性管理、ITサービス管理、情報セキュリティ管理、サプライヤ管理。
サービスソリューション設計→事業部門と合意した要件(サービス要件、非機能要件、ユーザーインターフェイス)をもとに設計する設計対象。
支援的な仕組みの設計(特にサービスポートフォリオ)→サービスポートフォリオ、システム管理ツール、ワークフローなどプロセスの活動を効率的に伝える仕組みやツールを設計対象とする。
技術アーキテクチャの設計→安全で障害弾力性のあるITインフラストラクチャ、アプリケーションなどのアーキテクチャ設計を対象とする。
プロセスの設計→プロセスの活動内容、インプット、アウトプット、役割、責任などを対象とする。
測定方法と測定基準の設計→プロセスの活動やプロセスの成果物(アウトプット) 管理するため、プロセスを監視測定する基準の設計。
サービスデザインパッケージ→ITサービスとその要件のすべての側面についてライフサイクルの各段階を通して定義する文書の事。
サービスデザインパッケージの内容→要件(事業要件、サービスの活用場所、サービスの事業窓口)、設計(サービスの機能要件、サービスレベル要件、運用管理要件)、サービスライフサイクル計画(サービスの移行計画、運用の全体的な戦略など)
サービスの自動化→サービスプロセスを自動化する事。有用性と保証を改善する。
サービス自動化のメリット→サービス品質の改善のばらつきの減少による有用性、保証の改善、コスト削減など。
サービス自動化のための4つ私信→①自動化する前にサービスプロセスを簡略化する。②活動の流れ、タスクの割り当て、情報の必要性、やりとりの明確化。③システムの技術の複雑性からユーザを保護する。④複雑な標準的でないまたは通常実施しないタスクは自動化を避ける。
4.2 サービスカタログ管理
サービスカタログ管理→ITサービスプロバイダが事業部門に提供しているサービスや、導入準備中のITサービスを作成管理する事。
サービスカタログ→サービスオペレーションの段階で顧客やユーザーに提供されている、ITサービスと顧客やユーザに提供することが承認済みで導入準備中のITサービスについて詳細をまとめたもの。
ビジネス・サービスカタログ→顧客に提供するITサービスの詳細をまとめたサービスカタログの事。
技術・サービスカタログ→事業部門内にITサービスを提供するため必要となるすべてのサービス(支援)をまとめたものの事。 
4.3 サービスレベル管理
サービスレベル管理→ITサービスの目標について事業部門の代表者と協議し文書化する。合意されたレベルでITサービスが提供されているかITサービスプロバイダの能力を監視、レビューしサービスレベルを維持向上させる事。
サービスプロバイダのタイプ→サービスプロバイダの典型的なビジネスモデルによる分類の事。
内部サービスプロバイダ→ITサービスを提供する事業部門内に存在するサービスプロバイダの事。
シェアド、サービス部門→内部サービスプロバイダの一部で、複数の事業部門で共有するITサービスを提供する部門の事。
外部サービスプロバイダ→外部顧客にITサービスを提供する部門の事。
SLR(Service Level Requirement)→ITサービスのあらゆる面に対する顧客の要件の事。
SLA(Service Level Agreement)→ITサービスプロバイダと顧客との間で文書化された合意であり、重要なサービス目標と両当事者の責任を定義したもの。
サービスレベルSLA→1つのSLAが1つのサービスを利用するすべての顧客を対象とする場合事。
顧客ベースSLA→1つの独立した顧客グループとその顧客が使用するSLAの事。
マルチレベルSLA→SLAの頻繁な更新を避けるため、企業レベル、顧客レベル、サービスレベルの3つ体系に分けることによって、SLAを使いやすいサイズに維持する。
OLA(Operational Level Agreement)→SLAを実現するため、ITサービスプロバイダと組織内でサービスの提供を支援する他部署との合意の事。
UC(Underpining Contract)外部委託契約→SLAを実現するため、ITサービスプロバイダと外部サプライヤとの間で交わされる契約の事。
サービス・レビュー →先期のサービス達成度、翌期の課題をもって確認するため顧客またはその代表と定期的に開催するレビューの事。
サービス改善計画(SIP(Service  Inprovement Plan))→プロセスまたはサービスに対する改善を実施するための正式な計画。
サービスレベルモニタリングチャート(SLAM(Service Level Agreement Monitoring))→サービスレベルの目標値に対してどの程度達成できたかといった達成度をモニタし報告するための有益な情報の事。
サービスレベルマネージャ→SLA、OLAを文書化する責任を持ち、SLAが満たされているかどうかのパフォーマンスを監視する。
SLAフレームワーク設計→サービスレベル管理をサービスカタログを利用して、組織のニーズに最も適したSLA体系を設計する事。
サービスレベル要件→サービスレベルが確定され、SLA体系について合意がされると策定される。
SLAに照らしたサービスパフォーマンスの監視→SLAの目標値を満たしているかサービスのパフォーマンスを監視する事。
可用性管理→可用性に関する要件をSLAのインプットとしてサービスレベル管理プロセスを提供し可用性が悪化することによって起きるSLA違反を削減する事。
キャパシティ管理→パフォーマンスに関する要件をSLAのインプットとしてサービスレベル管理プロセスに提供する。
サプライヤ管理→SLAと整合性が取れるようにサプライヤと契約する事。
情報セキュリティ管理→SLAと整合性が取れるように情報セキュリティを管理する事。
変更管理→SLAに関する変更を管理する。
インシデント管理→SLAの目標値いないでインシデントを管理する事。
4.4 キャパシティ管理
キャパシティ管理→ITサービス/システムのキャパシティ・パフォーマンスが適切な時期に最も費用対効果に優れた方法で顧客、ユーザに現在および今後のニーズに対応できるようにする事。
キャパシティ計画→ITサービスに必要となるリソースを管理するために使用し、事業の需要を予測したシナリオ及び合意済みのサービスレベルの目標を達成するための原価計算済み代案が含まれるもの。
事業キャパシティ管理→ビジネスのニーズと将来の事業計画を把握し将来必要となるキャパシティを適切な時期に計画実装すること。
サービスキャパシティ管理→ITサービスのパフォーマンスとキャパシティを把握することを責務としキャパシティ計画で使用するため各ITサービスで使用するリソースと使用状況を収集し記録し分析する事。
コンポーネントキャパシティ管理→構成アイテムのキャパシティパフォーマンスを把握することを責務とする。サービスキャパシティ管理に使用するため、データ収集、記録、分析すること。
4.5 ITサービスの継続性管理
ITサービスの継続性管理→IT技術及びサービスに必要な設備を要求、合意された時間内に確実に再開できるようにすることで事業計測性管理プロセスを全体を支援する事。
BCP(Business Continuity Plan)事業継続性計画→ビジネス・プロセス中断後にビジネス・プロセスを回復するために必要なステップを定義した計画でITサービス継続性計画、事業継続性計画の重要な部分を占める。
BCM(Business Continuity Management)事業継続性管理→事業に深刻なインパクトを与える可能性があるリスクを管理し、組織がいつでも少なくとも事前に定義した最低限のレベルで事業を継続できることを確実にすること。
BIA(Business Inpact Analysis)ビジネスインパクト分析→サービスが中断することによる事業へのインパクトを定量化すること。
リスク・アセスメント→事業にとっての資産価値を分析し、資産に対する脅威を識別して脅威に対する各資産の脆弱性を評価する事。
RA(Risk Analysis)リスク分析→継続性に対する潜在的な脅威とその脅威が現実になる可能性を識別するためのリスク識別のリスクアセスメントの事。
リスク低減手段→リスクを評価し、事業及びあるいはITサービスの復旧に対する潜在的な要件を低減すること。
復旧オプション→サービスの中断に対応するための戦略。
手作業のワークアランド→ITサービスが再開するまでの2.3日間、1時的な措置としてITを使わず手作業でビジネスが回るようにする方法。
相互協定→類似技術を使用する組織同士が合意し、非常時に助け合う方法。
段階的復旧(コールドスタンバイ)→復旧時に「場所」だけを用意しておき、非常時に機器を持ち込んでシステムを再開する方法。
中間的復旧(ウォームスタンバイ)→復旧用に「場所」と「機器」だけを用意しておき非常時にはデータへのバックアップから復旧することでシステムを再開する方法。
高速復旧(ホットスタンバイ)→復旧用に「場所」と「機器」と「データ」だけを用意しておき非常時にデータの同期をとる事でシステムを再開する方法。
即時的復旧(ホットスタンバイ)→復旧用に「場所」と「機器」と「データ」と「サービス」を用意しておき、常にデータとシステムの同期をとれているバックアップセンターを用意する事。非常時には即座にサービスが復旧できる方法。
4.6 可用性管理
可用性管理→事業と顧客に利益を提供できるように費用対効果の高い方法でITサービス、ITインフラストラクチャ、サポートする組織の可用性を最適化・改善するプロセス。サービス可用性、コンポーネント可用性の2つのレベルがある。
コンポーネント可用性→サービスを構成するサーバやアプリケーションなどの可用性。
サービス可用性→サービスそのもの可用性。
可用性(Availability)→サービス、コンポーネント、構成アイテムが必要とされた時に合意された機能を実行する能力の事。
可用性(%)=(合意済みサービス時間-停止時間)/合意済みサービス時間×100(%)→可用性の計算式。
信頼性→サービス、コンポーネント、構成アイテムが中断せず長く合意された機能を実行できるかを示す指標。
平均サービス・インシデント間隔(MTBSI:Meam Time Between Service Incident)→信頼性を測定・レポートする。
平均故障間隔(MTBF:Meam Time Between Failures)→信頼性を測定・レポートする。
平均サービス・インシデント間隔(時間)=使用可能な時間/サービス中断回数→MTBSIの計算式。
平均故障間隔(時間)=(使用可能な時間-総停止時間)/サービス中断回数→MTBFの計算式。
保守性→障害発生後、サービス、コンポーネント、構成アイテムが迅速かつ効果的に稼働状態に回復できるかを示す指標の事。
平均サービス回復時間(MTRS:Meam Time to Restore Service)→保守性を計算する際に使用する。
平均サービス回復時間(時間)=総停止時間/サービス中断回数→MTRSの計算式。
サービス性→サードパーティ・サプライヤが持つ契約条件を満たす能力の事で、サードパーティ・サプライヤとの契約には構成アイテムに対して合意したレベルの信頼性、保守性、可用性が記載されている。
重要ビジネス機能(VBF:Vital Business Function)→ITサービスによって支えられているビジネスプロセスの事業上重要な(欠かすことのできないもの)要素を表にしたもの。
拡張版インシデントライフサイクル→インシデントのライフサイクルの詳細で検出、診断、修理、復旧、回復の段階がある。インシデントのインパクトを増大させたすべての要因を把握しインパクトをコントロール低減させる方法を計画するときに使用される。
4.7 情報セキュリティ管理
情報セキュリティ管理→ITセキュリティと事業セキュリティを整合させること、およびすべてのサービスとサービスマネジメントの活動において情報セキュリティが効率的に管理されている事。
可用性・気密性・完全性(CIA)→情報セキュリティ管理のプロセスできちんと管理することに焦点をあてている3つのポイント。
機密性(Confidentiality)→情報を知る権限を持つ人間だけに閲覧可能になっている。また情報を知る権限を持つ人だけに公開される情報セキュリティ管理の概念のひとつ。
完全性(Intergrtiy)→情報が完全かつ正確で許可されていない修正から保護されていることの情報セキュリティ管理の概念のひとつ。
可用性(Availability)→必要とするときに、情報を入手および利用可能な事。また情報を提供するシステムが攻撃に対して適切に対処し、障害から復旧、または障害を防ぐことことができる状態の情報セキュリティ管理の概念のひとつ。 
情報セキュリティ方針→情報セキュリティ管理に対する組織のアプローチを統制する方針の事で情報セキュリティの全領域を網羅し事業とITのトップマネジメントにより認可される。 
情報セキュリティ管理システム(ISMS:Informaetion Security Management System)→組織が情報セキュリティ管理の達成目標を確実に満たすことができるようにするための方針、プロセス、指針、ツールの枠組み。 
ISO/IEC27001→情報セキュリティのフレームワークの国際規格。 
情報セキュリティの管理システムの4つのP→People(人材)、Products(プロダクト)、Process(プロセス)、Partners(パートナー) 
4.8 サプライヤ管理
サプライヤ管理→良質のITサービスを事業部門に途切れることなく提供するサービスを管理し投資に見合う価値を得られるようにするプロセス。
サプライヤ→ITサービスを提供するために必要となる商品またはサービスの供給を責務とするサードパーティのこと。戦略的サプライヤ、戦術的サプライヤ、運用上のサプライヤ、コモディティサプライヤの4つに分類される。
戦略的サプライヤ→長期的な計画を推進するためにITサービス・プロバイダと戦略に関する機密情報をを共有するサプライヤ。戦略的な機密情報を共有できる上級マネージャーが関与し、定期的な打ち合わせやパフォーマンスのレビューを頻繁に行うサプライヤ。ネットワークのサービスサポートを供給する世界規模のネットワークサービスプロバイダなどが例にあげられる。
戦術的サプライヤ→重要な商業活動や事業でITサービスプロバイダとやり取りがあるサプライヤ。通常中級マネージャによって管理され定期的な打ち合わせとパフォーマンスのレビューをするサプライヤ。ハードウェアの故障を解決するハードウェアの保守組織や基幹システムのアウトソーサーなど。
運用上のサプライヤ→運用中の製品やサービスの供給でITサービスプロバイダとやり取りがあるサプライヤ。通常運用現場の責任者である運用マネージャによって管理され頻度は少ないが定期的な打ち合わせとパフォーマンスのレビューを実施する。社内イントラネット向けのウェブサイト運営などインパクトの低いサプライヤ。
コモディティサプライヤ→ITサービスプロバイダに容易に入手できる製品とサービスを提供するサプライヤ。
契約→複数の当事者間における法的拘束力のある合意のこと。SLA、OLAとの違いは法的拘束力の有無。
契約の付則→セキュリティ要件、事業継続性要件、情報開示の合意など。
サプライヤ契約データベース(SCD:Supplier Contracts Database)→サプライヤの契約のライフサイクル(契約の確立、契約の更新、終了、契約の評価など)を通じてサプライヤの管理に使用するデータベースまたは構造化された文書のこと。各サプライヤが提供するサービス、製品に関する情報、サプライヤとの契約情報など。
サービスナレッジ管理システム(SKMS)→サプライヤ契約データベースはサービスナレッジ管理システムに含まれITサービスプロバイダに必要な情報を提供する。
ITサービスの提供戦略の選択肢(ソーシング戦略)→ITサービスの提供形態の選択肢の全体。
アウトソーシング→ITサービスの提供に必要なリソースを外部組織から調達する事。サービスの設計、開発、運用、保守などを外部組織に委託する。
インソーシング→ITサービスの提供に必要なリソースをすべて社内でまかなうこと。ITサービスプロバイダ内のスタッフが設計、開発、運用、保守を行う。
コンソーシング→アウトソーシングとインソーシングを組み合わせた形態。複数の外部組織と社内のリソースを両方使用し、ITサービスを提供する事。ITサービスプロバイダのスタッフが複数の外部組織の協力を得ながらサービスの設計、開発、運用、保守を行う。
パートナーシップ(マルチソーシング)→専門能力や市場機会を相互に活用するため複数の組織が戦略的に連携し、ITサービスを提供する事。複数の企業の戦略的提携に基づいてサービスを提供する。
アプリケーション・サービス供給→アプリケーション・サービスプロバイダ(ASP)が提供するアプリケーション(ネットワーク経由で利用可能)をASPと正式に協定を結んで提供される。ネットワーク経由で利用できる営業支援システムなど。
ビジネスプロセスアウトソーシング(BPO:Business Process Outsourcing)→コストの安い地域にビジネス・プロセス機能をソーシングすること。総務、給与計算関係のデータ入出力を中心とした業務やコールセンタ運用など。
ナレッジプロセスアウトソーシング(KPO:Knowledge Process Outsourcing)→ビジネス・プロセスや機能をソーシングする点はBPOと同じだが、さらに1歩進めて特殊で高い専門能力が必要なビジネスプロセスや機能をソーシングする。コンピュータのソフトウェアの研究開発部門など。



スポンサードリンク