マインドマップギャラリー 情報技術サービス ISOIEC20000-2018 バージョン(条項分析付き)
これは、約款の理解、特殊な用語、一連の規格などを含む、約款分析マインド マップを含む情報技術サービス ISO/IEC20000-2018 バージョンに関する記事です。
2023-11-14 11:19:37 に編集されました情報技術サービス ISO/IEC20000
シリーズ規格
ISO/IEC20000-1 サービスマネジメントシステム要件
ISO/IEC20000-2 サービスマネジメントシステム導入ガイド
ISO/IEC20000-3 ISO/IEC20000-1 範囲定義および適合性ガイドライン(2019 年版)
ISO/IEC20000-4プロセス参照モデル
ISO/IEC20000-5 ISO/IEC20000-1実施計画例
ISO/IEC20000-6 サービス管理システムを監査および認証する組織の要件
ISO/IEC20000-7 ISO/IEC:20000-1:2018、1SO9001:2015 と ISO/IEC:27001:2013 の統合と関係に関するガイダンス
ISO/IEC20000-8プロセス評価モデル
ISO/IEC20000-9 ISO/IEC20000-1をクラウドサービスに適用するためのガイドライン
ISO/IEC20000-10
特別規約
資産 資産
組織にとって潜在的または実際の価値を持つ要素、物、またはエンティティ
注 1: 価値には、有形または無形、財務的または非財務的なものがあり、リスクと負債の考慮が含まれます。資産の耐用年数のさまざまな段階でプラスにもマイナスにもなり得ます。
注 2: 物理的資産とは、通常、組織が所有する設備、在庫、資産を指します。物理的資産は、リース、ブランド、デジタル資産、使用権、ライセンス、知的財産、評判、契約などの非物質的な資産である無形資産の対極です。
注: 資産は構成アイテム (構成アイテム: サービスを提供するために制御する必要がある要素) になることもありますが、一部の構成アイテムは資産ではない場合があります。
外部サプライヤー 外部サプライヤー
サービスの計画、設計、変換、提供または改善に参加する組織との契約。 コンポーネントまたはプロセスにサービスを提供する組織外の関係者。
注: 外部サプライヤーには、指定された主要サプライヤーが含まれますが、その下請けサプライヤーは含まれません。
注: 組織の外部の組織
社内サプライヤー 社内サプライヤー
SMS の範囲外にある、サービス、サービス コンポーネント、またはプロセスの計画、設計、変換、提供、または改善を促進するための文書化された契約を結んだ、より大きな組織の一部。
例:調達、インフラ、財務、人事、設備など(部門) 注: 内部プロバイダーと SMS スコープの組織はどちらも、同じ大規模な組織の一部です。
イベント 事件
サービスの予期せぬ中断、およびサービス品質の低下を引き起こすが、顧客またはユーザーのサービスにはまだ影響を与えていない問題。
情報セキュリティインシデント 情報セキュリティインシデント
事業運営を危険にさらしたり、情報セキュリティを脅かしたりする可能性が非常に高い、単一または一連の予期せぬまたは有害な情報セキュリティ イベントで構成されます。
情報セキュリティは、情報の機密性、完全性、可用性を保護します。
既知のエラー 既知のエラー
問題の根本原因が判明したか、サービスへの影響を軽減または排除する方法が判明しました。
質問 問題
イベントの 1 つ以上の実際の原因または一時的な原因。
リリース リリース
サービスまたはサービス コンポーネントに対する 1 つ以上の変更と、1 つ以上の変更の結果としてランタイム環境にデプロイされた新しいサービスの組み合わせ。
変更要求 変更のリクエスト
サービス、サービス コンポーネント、または SMS への変更の提案。
注: サービスの変更には、新しいサービスの提供、サービスの移行、および不要になったサービスの削除が含まれます。
サービスカタログ サービスカタログ
組織が顧客に提供するサービスに関する情報。
サービスコンポーネント サービスコンポーネント
他の要素と組み合わせて完全なサービスを提供するサービスの一部。 例: インフラストラクチャ、アプリケーション、ドキュメント、ライセンス、情報、リソース、サポート サービス
注: サービス コンポーネントには、構成アイテム、資産、またはその他の要素を含めることができます。
サービスレベル契約 サービスレベル契約。
サービスとその合意されたパフォーマンスを定義する、組織と顧客の間の文書化された合意。
注 1: サービス レベル契約は、組織と、サプライヤーとしての外部プロバイダー、内部プロバイダー、または顧客との間でも確立される場合があります。
注 2: サービス レベル アグリーメントは、契約またはその他の種類の文書化された契約に含まれる場合があります。
サービスレベル目標 サービスレベル目標
組織が約束するサービスの具体的な測定可能な特性。
サービス管理 サービス管理
価値を提供するためにサービスを計画、設計、変換、提供、改善するために使用される組織の活動とリソースを指示および制御する一連の機能とプロセス。
注: この規格は、条項および副条項を通じて一連の要件を規定しています。各組織は、これらの要件をプロセスに組み合わせる方法を選択できます。その中で、サブ句を使用して SMS を整理するプロセスを定義できます。
サービスのお申し込み サービス要求
情報、相談、サービスへのアクセス、または事前承認の変更のリクエスト。
変換する 遷移
新しいサービスまたは変更されたサービスを運用環境に移動したり、運用環境から移動したりすることに関連するアクティビティ。
用語の理解
序文
「組織」とは、サービスを管理し、顧客にサービスを提供するサービス管理組織内の組織です。サービス管理システムの範囲内の「組織」は、大企業の部門などの組織の一部である場合があります。サービスを管理し、顧客に提供する組織または組織の一部は、サービス プロバイダーと呼ばれることもあります。
組織がこの規格への準拠を主張する場合、組織の性質にかかわらず、第 4 章から第 10 章の内容を削減することはできません。第 4 章から第 5 章では、組織自体がこの規格に準拠していることの証拠を提出することが求められます。他社からの提供はできません。第 6 章から第 10 章の内容は、他の当事者によるサポートも可能ですが、8.2.3 に定める条件を満たす必要があります。
4 組織環境
4.1 組織とその環境を理解する
組織は、その意図に関連し、SMS の意図した結果を達成する能力に影響を与える外部および内部の事項を特定する必要があります。
組織の価値観、文化、知識、パフォーマンスなどの内部要因。例えば、内部監査結果や自己評価結果、品質コストデータ分析、技術動向情報分析、顧客からのフィードバック、苦情、レビュー結果、実際および期待される社内価値観や文化、組織パフォーマンスなど。
外部要因には、国際的、国家的、地域的、地方の政治的、経済的、社会的、法律的、技術的、競争的、市場的、文化的環境要因が含まれます。例えば、国際貿易情勢、法令、経済環境や発展動向などです。
例証します: 1. 要因には、考慮する必要があるプラスおよびマイナスの要素または条件が含まれる場合があります。 2. 組織は常に変化しているため、組織の環境、特に組織の目標に影響を与える変化や傾向を定期的に監視する必要があります。
4.2 関係者のニーズと期待を理解する
組織は、SMS およびサービスに関連する当事者、およびこれらの当事者の関連要件を特定するものとします。 注: 利害関係者からの要件には、SMS およびサービスに関連するサービス、パフォーマンス、法的規制要件、および契約上の義務が含まれる場合があります。
例証します: 1. 顧客、ユーザー、コミュニティ、外部サプライヤー、規制当局、公的機関、非政府機関、投資家、従業員など、組織のサービス管理システムの範囲外の部分が含まれる可能性があります。 2. 関係者が要求する表現形式は、主に契約書、協定書、書簡、提案書、議事録など、多岐にわたります。
4.3 サービス管理システムの範囲の決定
組織は、SMS の範囲と適用可能性を判断して、その範囲を決定する必要があります。 この範囲を決定する際、組織は次の点を考慮する必要があります。 a) 4.1 に記載の社外および社内の事項 b) 4.2 に記載されている要件 c) 組織が提供するサービス。 SMS スコープの定義には、スコープ内のサービスと、サービスを管理および提供する組織の名前を含める必要があります。 SMS スコープは文書化された情報を形成し、利用できるようにする必要があります。 注 1: ISO/IEC20000-3 は範囲の定義に関するガイダンスを提供します。 注 2: SMS スコープ定義は、どのサービスがスコープに属するかを宣言します。組織が提供するサービスの全部または一部である場合があります。
範囲の例: 1. 組織範囲:○○社のITサービス事業に関わる全ての部門および担当者が対象となります。具体的な関係部門については、組織構造をご参照ください。 2. 場所:宮古地区宮道路沿い宮ビル2階。 3. サービス内容:ネットワークシステム、データベースシステム、アプリケーションシステム、サーバーの保守サービスを提供します。
4.4 サービス管理体制
組織は、必要なプロセスとその相互作用を含む、この標準の要件に従って SMS の実装、保守、および継続的改善を確立するものとします。
5 リーダーシップ
5.1 リーダーシップとコミットメント
経営トップは、次の活動を通じて SMS に対するリーダーシップとコミットメントを示す必要があります。 a) サービス管理ポリシーとサービス管理目標が確立され、組織の戦略的方向性と一致していることを確認します。 b) サービス管理方針をサポートし、サービス管理目標とサービス要件を達成するためのサービス管理計画の確立、実施、維持を確実に行う。 c) SMS およびサービスに関連する意思決定を行うために、適切なレベルの権限が割り当てられていることを確認します。 d) 組織とその顧客にとっての価値が確実に決定されるようにする e) サービスのライフサイクルに関与する他の関係者を確実に管理する。 f) SMS 要件が組織のビジネス プロセスに統合されていることを確認します。 g) SMS およびサービスに必要なリソースが利用可能であることを確認します。 h) 効果的なサービス管理、サービス管理目標の達成、価値の提供、SMS 要件の遵守の重要性を伝える。 i) SMS が期待どおりの結果を達成することを確認する j) SMS とサービスの有効性に貢献するよう関係者を指導し、サポートする k) SMS とサービスの継続的な改善を促進する。 l) 共有の責任領域に適切なリーダーシップを発揮するために、他の関連する管理職をサポートする この規格における「ビジネス」への言及は、組織の存在目的の中心となる活動を意味すると広く解釈される可能性があります。
理解:8つの保証、1つのコミュニケーション、1つの指導、1つの推進、および1つのサポートを通じて、マネジメントシステムの期待される結果が確実に達成されるようにするための、ITサービスマネジメントシステムにおけるトップマネージャーの役割と役割を強調します。
5.2 ポリシー
5.2.1 サービス管理ポリシーの確立 経営トップは、次のようなサービス管理ポリシーを確立する必要があります。 a) 組織の意図に適切であること。 b) サービス管理目標を設定するためのフレームワークを提供する。 c) 適用される要件を満たすという約束を含める。 d) サービス管理システムとサービスの継続的改善への取り組みが含まれます。
5.2.2 サービス管理ポリシーの伝達 サービス管理ポリシーは次のことを行う必要があります。 a) 文書化された情報が利用可能になります。 b) 組織内で伝達される。 c) 該当する場合、関係者が利用可能。
理解する: ポリシーは、組織のトップマネージャーによって正式に発行される仕事の意図と指示であり、内部的には行動の方向性と基準であり、外部的には行動の目的とコミットメントです。この標準では、トップマネジメントに対し、一貫して適切で組織の戦略的方向性と一致するサービス管理ポリシーを確立し、維持することが求められています。
5.3 組織の役割、責任、権限 経営トップは、サービス管理システムおよびサービス関連の役職に関連する責任と権限が組織内で割り当てられ、伝達されるようにする必要があります。 経営トップは以下の責任と権限を割り当てる必要があります。 a) サービス管理システムがこの規格の要件を満たしていることを確認します。 b) サービス管理システムのパフォーマンスを経営トップに報告します。
経営トップに対し、関連する役職の責任と権限を割り当てることを明確に要求し、責任と権限を割り当てる際には以下の点を考慮して、当該役職およびその他の関係者がそれらを正しく理解できるようにする。 ——ビジネスプロセスとその有効性要件。 ——既存の組織構造、ポリシー、社内システム、職務要件。 ——現在の従業員の能力と資格は、割り当てられた責任が必要な能力と資格と一致していることを保証する必要があります。 ——人員、設備や設備、技術、資金などの利用可能なリソース 責任と権限の割り当ては IT サービス管理システムの要件を満たす必要があり、役割の割り当てではプロセス アクティビティのニーズを考慮する必要があります。プロセスの出力が期待を確実に達成するため。 IT サービス管理システムのパフォーマンスと改善の機会を経営トップおよび組織内に報告するための人員と責任を割り当てる必要があります。責任と権限の分散は、顧客重視の実現に役立つものでなければなりません。変更が発生した場合の IT サービス管理システムの整合性も確保する必要があります。たとえば、担当者の異動を伴わずに複数の部門にわたる責任を調整すると、特定の作業が中断されてしまう可能性があります。
6企画
6.1 リスクと機会への対応
6.1.1 サービス管理システムを計画する際、組織は 4.1 に記載の事項と 4.2 に記載の要件を考慮し、対処する必要があるリスクと機会を決定するものとします。 a) サービス管理システムが期待される結果を達成できることを確認します。 b) 悪影響を予防または軽減する。 c) サービス管理システムの継続的改善を実現します。
6.1.2 組織は以下を特定し、文書化するものとします。 a) 以下に関連するリスク: 1) 組織。 2) サービス要件が満たされていない場合。 3) サービスライフサイクルへの関係者の参加。 b) SMS サービスのリスクと機会が顧客に与える影響。 c) リスク許容基準。 d) リスク管理に使用される方法。
6.1.3 組織は以下を計画するものとします。 a) これらのリスクと機会に対処し、優先順位を付けるための行動。 b) 方法: 1) これらの対策をサービス管理システムのプロセスに統合し、実装します。 2) これらの対策の有効性を評価する。 注 1: リスクと機会に対応するためのオプションには、リスクの回避、機会を追求するためにリスクを取るまたはリスクを増やす、リスク源の排除、リスクの可能性や結果の変更、合意された措置によるリスクの軽減、他の当事者とのリスクの共有、または正式な手段によるリスクの共有が含まれます。リスクを受け入れることを決意します。
1. リスクとは、不確実性、すなわち、一定の環境下、一定期間内に客観的に存在し、組織の目標や期待される成果の実現に影響を与えるさまざまな不確実要素の影響です。不確実性の影響はプラスにもマイナスにもなり得ます。 2. ISO/IEC20000-1:2018 には、「リスクと機会」に関する以下の条項があります。 1) 序章では、機会とリスクの考え方の概念を説明します。 2) 条件: 3.1.20 リスク、3.2.1 資産、3.2.29 価値。 3) 第 6 章では、サービス管理に関連するリスクと機会を特定し、適切な対応策を策定することが組織に求められています。 ——6.1.1 サービス管理システムの計画: 組織は、4.1 に記載されている品質と 4.2 に記載されている要件を検討し、対処する必要があるリスクと機会を決定するものとします。 ——6.1.3 組織的な対応: a) リスクと機会に対処するための対策と優先順位。 ——6.3 サービス管理システムを計画する 計画では、サービス管理方針、サービス管理基準、リスクと機会、サービス要件、およびこの基準の要件を考慮する必要があります。 4) 第 8 章では、必要なサービス ミックスを決定および提供する際にリスクを考慮するよう組織に求めています。 - 8.2.2 サービスの計画: 既知の制限とリスクを考慮して、組織は、一貫した方法でサービス管理ポリシー、サービス管理目標、およびサービス要件を満たすサービスの変更を提案する必要があります。 - 8.3.4.1 外部サプライヤーの管理: 組織は、顧客のサービス レベルとの一貫性について外部サプライヤーのサービス レベル基準またはその他の契約上の義務をレビューし、特定されたリスクを管理するものとします。 - 8.5.1.3 変更アクティビティ管理: 組織および関係者は、変更要求の承認と優先順位に関する決定を下すものとします。意思決定では、リスク、ビジネス上の利点、実現可能性、財務上の影響を考慮する必要があります。 ——8.7.1 サービス可用性管理: 計画された間隔で、サービス可用性に関するリスクを評価し、文書化した情報を保持するものとします。契約の要件では、関連するビジネス要件、サービス要件、SLA、およびリスクを考慮する必要があります。 8.7.2 サービス継続性管理: 計画された間隔で、サービス継続性に関連するリスクを評価し、文書化した情報を保持するものとします。組織はサービス継続要件を決定するものとします。契約の要件では、関連するビジネス要件、サービス要件、SLA、およびリスクを考慮する必要があります。 ——8.7.3 情報セキュリティ管理 5) 第 9 章の業績評価では、マネジメントレビューにリスクを考慮することが求められている ——9.3 「K) マネジメントレビューにおけるリスク評価の結果とリスクと機会への対応策の有効性」
6.2 サービス管理の目標と実施計画
6.2.1 目標を設定する 組織は、関連する機能およびレベルでサービス管理目標を確立する必要があります。 サービス管理の目標は次のとおりです。 a) サービス管理ポリシーと一致していること。 b) 測定可能。 c) 適用される要件を検討する。 d) 監視されること e) コミュニケーションを取る。 f) 必要に応じて更新します。 組織は、サービス管理目標に関する文書化された情報を維持する必要があります。
6.2.2 目標達成のための計画 サービス管理目標の達成方法を計画するとき、組織は次のことを決定する必要があります。 a) 何をすべきか。 b) どのようなリソースが必要か。 c) 責任者は誰ですか? d) いつ完成するか。 e) 結果を評価する方法。
組織は、サービス管理システムに必要な関連機能、レベル、およびプロセスでサービス管理目標を設定する必要があります。プロセスのサービス管理目標を設定することは、この規格で明確に記載された新しい要件です。 サービス管理目標の確立とサービス管理目標の達成計画は、組織が行動の一貫性を達成するのに役立ちます。組織は、何をするか (Which)、どのリソースが必要か (What)、誰が責任を負うか (Who)、いつ完了するか (When)、結果をどのように評価するかを計画することによって、組織が行うべきことを定義できます。 (How)すなわち「4W1H」活動 サービス管理基準の策定とその実施については、計画・検討・実施要件・点検・改善の順に計画します。
6.3 サービス管理システムの計画 情報技術 - サービス管理 - サービス管理システム要件 1S0/IEC 20000-1:2018 組織はサービス管理計画を作成、実施、維持するものとします。計画では、サービス管理ポリシー、サービス管理の目標、リスクと機会、サービス要件、およびこの標準の要件を考慮する必要があります。 サービス管理計画には、以下を含めるか、関連するインデックスを含める必要があります。 a) サービスリスト。 b) サービス管理システムに影響を与える既知の制限。 c) 関連するポリシー、標準、法的規制、契約上の要件などの義務、およびこれらの義務が SMS およびサービスでどのように履行されるか。 d) サービス管理システムとサービスの権限と責任。 e) サービス管理システムとサービスを運営するために必要な人員、技術、情報、および財源。 f) サービスのライフサイクルに関与する他の関係者との協力方法。 g) SMS をサポートするために使用されるテクノロジー。 h) SMS とサービスの有効性を測定、監査、報告し、改善する方法。 他の計画活動はサービス管理計画と一致している必要があります。
1. ライフサイクルに関わる他の関係者と協力する方法を検討することが重要です。 2. ITIL では、情報技術サービスのライフサイクルを、サービス戦略、サービス設計、サービス変革、サービス運用、継続的改善を含む 5 つの段階として定義しています。情報技術サービスがさまざまな段階にある場合、対応するプロセスと仕様が存在します。
7 サポート
7.1 リソース 組織は、サービス要件を満たし、サービス管理目標を達成するために、サービス管理システムを確立、実装、維持し、継続的に改善し、サービスを運用するために必要な人的、技術的、情報および財政的リソースを特定し、提供するものとします。
1. リソースには、人的リソース、インフラストラクチャ、プロセス動作環境、監視および測定リソース、技術的および財政的リソース、組織的知識などが含まれます。 2. 必要なリソースを決定する際、組織は、既存の資材、人材と能力、機械設備、情報通信システムと施設が運用要件を満たすことができるかどうかなど、現在の能力と制限を考慮する必要があります。どのようなリソースが必要なのかを把握し、リソース要件を満たすために外部から提供されるリソースを含むリソースが確実に提供されるようにします。
7.2 機能 組織は次のことを行う必要があります。 a) 組織の SMS およびサービスのパフォーマンスと有効性に影響を与える、組織の管理下にあるスタッフの必要な能力を決定する。 b) 上記の人員が適切な教育、訓練、または経験に基づいて職務を遂行する能力があることを確認する。 c) 該当する場合、必要な能力を獲得するための措置を講じ、講じた措置の有効性を評価する。 d) 能力の証拠として適切な文書化された情報を保持する。 注: 適用される措置には、たとえば、既存の従業員に対するトレーニング、指導、または任命の提供、有能な人材の雇用または契約が含まれる場合があります。
7.3 意識 組織の管理下で働く人々は次のことを理解する必要があります。 a) サービス管理ポリシー。 b) サービス管理目標。 c) 仕事に関連したサービス。 d) パフォーマンスの向上による利点を含む、サービス管理システムの有効性への貢献。 e) サービス管理システム要件への違反による影響。
7.4 通信 組織は、サービス管理システムおよびサービスに関連する以下を含む内部および外部のコミュニケーションのニーズを決定するものとします。 a) 何を伝えるべきか。 b) いつ通信するか。 c) 誰と通信するか。 d) コミュニケーションの方法。 e) コミュニケーションの責任者は誰ですか。
7.5 文書化された情報
7.5.1 一般 組織のサービス管理システムには次のものが含まれている必要があります。 a) この規格で要求される文書化された情報。 b) サービス管理システムの有効性のために組織が必要と判断した文書化された情報。 c) 組織ごとに、サービス管理システムに関連する文書化された情報の詳細レベルが異なる場合があります。その理由は次のとおりです。 1) 組織の規模とその活動、プロセス、製品およびサービスの種類。 2) プロセス、サービス、およびそれらの相互作用の複雑さ。 3) 人材の能力。
7.5.2 作成と更新 文書化された情報を作成および更新するとき、組織は以下を適切に行う必要があります。 a) 識別と説明(タイトル、日付、著者または引用番号など)。 b) 形式(言語、ソフトウェアのバージョン、グラフィックスなど)および媒体(紙、電子など)。 c) 適合性と適切性のレビューと承認。
7.5.3 文書化された情報の管理
7.5.3.1 この規格で要求されるサービス管理システムおよび文書化された情報は、次のことを保証するために管理されなければなりません。 a) 必要なときに必要な場所での使用に利用可能かつ適切である。 b) 適切に保護されていること(機密性の喪失、不適切な使用、完全性の喪失など)。
7.5.3.2 文書化された情報を管理するために、組織は該当する場合、次の活動に取り組むものとします。 a) 配布、アクセス、検索および使用。 b) 可読性の維持を含む保管と保護。 c) 変更管理 (バージョン管理など)。 d) 保存と処理。 サービスマネジメントシステムの企画・運用に必要と組織が判断した外部文書情報を適切に特定し、管理するものとします。 注: アクセスとは、文書化された情報の閲覧のみを許可する、または文書化された情報の閲覧と更新を許可および許可するなどの決定を意味します。
7.5.4 サービス管理システムの文書化情報 サービス管理システムの文書化された情報には、以下が含まれる必要があります。 a) サービス管理システムの範囲。 b) サービス管理のポリシーと目標。 c) サービス管理計画。 d) 管理ポリシー、情報セキュリティポリシー、およびサービス継続計画を変更します。 e) 組織のサービス管理システムのプロセス。 f) サービス要件。 g) サービスカタログ。 h) サービス レベル アグリーメント (SLA)。 i) 外部サプライヤーとの契約。 j) 社内サプライヤーまたはサプライヤーとしての顧客との契約。 k) この規格で要求される手順。 |) この標準への準拠と組織のサービス管理システムの関連証拠を証明するために必要な記録。 注: 条項 7.5.4 には、サービス管理システムに関する重要な文書化された情報のリストが記載されています。この規格には、文書化または記録する必要がある他の情報の文書化に関する特定の要件もあります。 1S0/IEC 20000-2 がガイダンスを提供します。
7.6 知識
組織は、SMS およびサービスの運用をサポートするために必要な知識を決定し、維持するものとします。 知識は関連性があり、適切な担当者が利用可能であり、アクセスできるものである必要があります。 注: 知識は組織、その SMS、サービス、および関連当事者に固有のものです。知識を使用および共有して、望ましい結果の達成をサポートし、 SMSとサービスの操作。
理解: 2018 年版で新たに追加された組織知識は、通常は経験から得られる組織に固有の知識であり、組織の目標を達成するために使用および共有される情報です。組織の内部開発によって生み出された知識と、組織の存続と発展に役立つ外部の知識が含まれます。 組織の認識は次のことに基づいて行われます。 1. 知的財産、経験から得た知識、プロジェクトの失敗および成功から学んだ経験と教訓、暗黙の知識と経験の取得と共有、プロセス、製品、サービスの改善結果などの内部情報源。 2. 外部情報源(規格、学術交流、専門家会議、ゲストや外部プロバイダーから収集した知識など) 組織は、変化するニーズや傾向に基づいて、必要な知識の習得を奨励する必要があります。知識の更新は急速に変化するため、組織は持続可能な発展を確保するために、内部および外部環境の変化に応じて知識を迅速に取得し、知識構造を更新する必要があります。
8ラン
8.1 運用計画と管理
組織は、要件を満たすために必要なプロセスを計画、実施、管理し、次の要件に従って第 6 章で特定された措置を実施するものとします。 a) 要件に従って確立されたプロセスパフォーマンス指標。 b) 確立されたパフォーマンス指標との一貫性を維持するためにプロセス管理を実装します。 c) プロセスが計画どおりに進むように、必要なレベルの文書化された情報を維持します。 組織は、SMS に対する計画された変更を管理し、変更による意図しない結果をレビューし、必要に応じて悪影響を軽減するための措置を講じるものとします (「 8.5.1)。 組織は、アウトソーシングされたプロセスが確実に管理されるようにするものとします(8.2.3 を参照)。
理解する: 1. この条項の目的は、組織内外の関係者の要件を満たすプロセスを計画、実行、および制御することです。これらのプロセスは、第 6 章で特定されたアクションの共通要素です。これらの共通要素は、これらを標準化し、組み合わせることができます。アクションをプロセスし、アクションジョブのパフォーマンスを向上させます。ここで明確にしておくべき重要なポイントは、「ステークホルダーの要件」、「プロセス」、「アクション」の 3 つです。 2. プロセス: ——システム認証の一般的なプロセス: 文書と記録の管理、内部監査、管理レビュー、および継続的改善。 ——システム計画のマクロプロセス:組織環境の特定、リーダーシップ計画、システム計画、およびシステム運用の監視、測定、分析、評価。 ——システム運用の具体的なプロセス:サービスポートフォリオ(サービス提供、資産管理など)、関係と契約(取引関係管理、サービスレベル管理など)、需要と供給(需要管理、容量管理など) )、サービス設計と変換(変更管理)、リリースと展開管理など)、解決と履行(サービスリクエスト管理、インシデント管理など)、サービス保証(サービス可用性、サービス継続性など)。 ——SMSのサポートに限らず、人事管理、調達管理、財務管理、サプライチェーン管理、生産オペレーション管理など、組織の基本的な管理プロセス。
8.2 サービスポートフォリオ
8.2.1 サービスの提供
組織は、活動とリソースの調整を確実にするためにサービス管理システムを運用する必要があります。組織は、サービスを提供するために必要な活動を実施するものとします。 注: サービス ポートフォリオは、提案されているサービス、開発中のサービス、サービス カタログで定義されている正式に提供されているサービス、オフラインになっているサービスなど、すべてのサービスのライフ サイクル全体を管理するために使用されます。サービス ポートフォリオ管理により、サービス プロバイダーが正しいサービス ポートフォリオを持っていることが保証されます。この標準におけるサービス ポートフォリオの活動には、サービス計画、サービス ライフ サイクルに関与する関係者の管理、サービス カタログ管理、資産管理、および構成管理が含まれます。
目標: サービスの収益を最大化し、リスクを最小限に抑えます。 測定: サービスのリスクと利点に関する測定方法を確立します (9.1 SMS およびサービスのモニタリング、測定、分析、評価と併せて)。 選択: サービスの選択と優先順位の方法。つまり、市場と顧客に向き合い、どのサービスを選択するか、およびサービスの優先順位をどのように設定するか。サービス計画 8.2.2 に対応します。 資産配分: サービスをサポートするためにどの資産が使用されるか、資産間の関係は何かなどを明確にします。資産投資はサービスコストの構成要素であり、資産管理 8.2.5 および配分管理に対応して、収益を最大化し、リスクを最小化するように最適化する必要があります。 8.2.6 ; 進化: 提案、開発、運用、オフラインに至るサービスの完全なプロセス。運用中のサービスは通常、サービス カタログ、特にサービス計画 8.2.2 に対応する特定の顧客との契約によって決定される「サービス カタログ」によって表されます。 、サービス ディレクトリ管理 8.2.4: 管理と制御: 8.2.3 に対応し、コストを管理し、リスクを軽減するために、ライフサイクル内の関係者を管理および制御します。 根拠: 財務管理はサービス ポートフォリオ管理への重要な入力であり、サービス提供に採用されているコスト構造を理解することで、企業はコストのベースラインを決定できる可能性があります。正確なコスト計算には、8.4.1 に対応する財務情報、サービス需要情報、組織のサービス能力情報などを理解する必要があります。
8.2.2 サービス企画・企画サービス
既存のサービス、新しいサービス、およびサービスの変更の要件を確認し、文書化する必要があります。 組織は、組織、顧客、ユーザー、関係者のニーズに基づいてサービスの重要性を特定するものとします。組織は、サービス間の依存関係とレプリケーション関係を特定して管理する必要があります。 既知の制限とリスクを考慮して、組織はサービスがサービス管理ポリシー、サービス管理目標、およびサービス要件と一致するようにサービスの変更を提案する必要があります。
1. 組織計画サービスの基礎として(サービスポートフォリオ管理の一環として)、さまざまな進捗状況におけるサービスとその要件(法律、規制、契約、および関係者のその他の要件を含む)を定期的に決定および記録します。組織が計画するサービスは、特定の顧客を対象としない市場志向のサービスである場合もあれば、特定の顧客を対象としたサービスである場合もあります。 2. 既存のサービスは、サービス カタログを通じて提供されます。新しいサービスは、運用可能で提供可能なサービスになるために、提案、開発、およびその他のプロセスを経る必要があります。サービスの変更は、既存または確立された SMS の変更管理を通じて管理されます。 3. サービスの重要性の決定は、組織の利益とコスト、サービスによってサポートされるビジネスの重要性と利点、および時間の緊急性 (可用性など) に関連します。他の関連当事者のコンプライアンス、サプライヤーの利益とコストなどの監督。サービスの重要性は、特定の顧客に合わせて調整することも、組織自体を中心に構築することもできます。重要度にかかわらず、分析・評価には評価モデルを確立する必要があります。 4. 優先順位を設定する際には、次の要素を考慮する必要があります。変更リクエストと新しいサービス、またはサービス管理目標を生成するビジネス ニーズ、変更リクエストとサービス提案を実装する際の投資、メリット、およびリスク。
8.2.3 サービスのライフサイクルを管理する関係者
8.2.3.1 組織は、サポート サービスのライフ サイクル中に活動の実行に関与する関係者に関係なく、この標準の要件と提供されるサービスに対して責任を負うものとします。 組織は、サービス ライフ サイクルにおける他の利害関係者を評価および選択するために、この基準を検証および適用するものとします。他の利害関係者は、外部サプライヤー、内部サプライヤー、および顧客として機能するサプライヤーである可能性があります。 他の利害関係者は、サービス管理システムの範囲内ですべてのサービス、サービス コンポーネント、またはプロセスを提供および運用してはなりません。 組織は以下を確認し、文書化するものとします。 a) 他の関係者によって提供および運営されるサービス。 b) 他の関係者によって提供および運営されるサービス コンポーネント。 c) 他の関係者が運営するサービス管理システムの範囲内で行われるプロセスまたは部分的なプロセス。 組織は、サービス要件を満たすために、組織自体またはその他の関係者が提供および運用するサービス管理システムの範囲内でサービス、サービスコンポーネントおよびプロセスを統合するものとします。組織は、サービスライフサイクルの計画、設計、変換、提供および改善活動を含む他の関係者と調整するものとします。
1. 評価基準: サービスに対する他の関係者の影響を考慮する必要があります。影響の決定的な要素には、サービスのライフサイクルにおける他の関係者の責任、参加の頻度、組織が支払うコスト/費用、およびその役割が含まれます。サービスの利点とリスクについては、これらの要素に基づいて評価モデルを構築する必要があります。 2. 選択基準: 他の当事者を選択する優先順位は、その影響の大きさに基づいて決定される必要があります。 組織が決定し記録すべきことは、他の当事者とその責任の特定に基づいて、他の当事者に対する 3 つの成果物 (つまり、サービス、サービスコンポーネント、サービスプロセス) のリストを作成し、それらを組織と比較することです。責任は統合されています。顧客のニーズを満たし、サービス管理目標を達成するため。目標は、サービスの効率を向上させ、コストとリスクを削減することであり、構成管理を通じて統合された方法と結果を達成する必要があります。
8.2.3.2 組織は、以下の管理を定義し、他の利害関係者に適用するものとします。 a) プロセスのパフォーマンスを測定および評価する。 b) サービス要件を満たすためのサービスおよびサービス コンポーネントの有効性を測定および評価します。 注: 1S0/1EC20000-3 は、サービス ライフ サイクル中に他の関係者を制御するためのガイダンスを提供します。
1. サービスおよびサービス要素の有効性の測定および評価は、以下の点に焦点を当てる必要があります。 ニーズを満たすサービスの有効性指標には、顧客のビジネス価値の満足度が含まれます。これらの指標におけるサービスの役割は、次の点に基づいて決定される必要があります。サービスの可用性、情報セキュリティ、サービスの継続性などの観点からの有効性指標に変換します。サービスの可用性は、キャパシティ、サービス コンポーネントの有効性指標 (可用性など) と密接に関連しています。測定の基礎は、サービス有効性指標とサービスコンポーネント有効性指標の対応関係を確立することです。対応関係は、サービスが完了するコンポーネントのパスを使用して確立できます。 2. 顧客のビジネス、サービス、サービスコンポーネントの関係を構成管理システムを通じて実現し、それに応じた測定および評価モデルを確立できます。
8.2.4 サービスカタログの管理
組織は 1 つ以上のサービス カタログを作成し、維持する必要があります。サービス カタログには、組織、顧客、ユーザー、およびサービスのその他の関係者、期待される結果、およびサービス間の依存関係を説明する情報が含まれている必要があります。 組織は、顧客、ユーザー、その他の関係者にサービス カタログ (の一部) への適切なアクセスを提供する必要があります。
1. サービス カタログのサービスには、ビジネス サービスとテクニカル サービスが含まれます。ビジネス サービスは、顧客のビジネス システムに直接必要なコンピューティング機能で構成されます。一方、テクニカル サービスは、組織が顧客のビジネス システムに提供する技術的なアクティビティで構成されます。 2. 一般的な技術サービスは、サーバー、ネットワーク機器、コンピューター室の空調装置などの情報資産の種類を第一の次元とし、その後、サーバーの設置および導入サービスなどの技術サービスを形成するために技術的な活動の次元を追加します。 、サーバー検査サービスなどのテクノロジー アクティビティは次のとおりです。インストールと展開には、初期インストールと展開、アップグレードとパッチ適用、変換、構成とテスト、資産の特定と監視、日常の検査と検査、トラブルシューティング、移行、バックアップ、およびリカバリ、監査と評価、放棄(アンインストール、切断、クリア、保存、破棄)など。 3. サービスの移転、サービスのオフライン、新しいサービスなどが発生した場合、組織はサービス カタログを適時に更新し、維持する必要があります。
8.2.5 資産管理
組織は、サービスの提供に使用される資産が第 6.3c) 条に基づくサービス要件および義務を満たすように管理されることを保証するものとします。 注: 1S055001 および 1S0/IEC19770-1 は、実装、運用資産、および IT 資産管理をサポートするための要件を特定します。 注: また、構成アイテムとして資産を使用する場合は、構成管理を参照してください。
1. 資産とは、サービスの提供に使用される資産を指します。これには、サービスの提供に不可欠な資産である限り、組織、顧客、サプライヤー、その他の当事者の資産が含まれる場合があります。 2. 情報資産の分類: コンピュータハードウェア、通信設備、物理的サポート設備などの物理的資産、文書やデータベースなどのソフトウェア、アプリケーションソフトウェア、システムソフトウェア、開発ツールやプログラムなど。製品を生産するか、意欲や評判などの無形資産を提供する能力。 3. 資産はライフサイクル全体にわたって管理される必要があります。組織は、他の当事者の資産についてのみ完全なライフサイクル管理を行うことができ、責任と管理作業は他の当事者に帰属します。 4. 組織は資産台帳を作成し、定期的に維持する必要があります。資産台帳の属性には通常、資産の大カテゴリ、中カテゴリ、小カテゴリ、名前、コード、ステータス、責任者、場所、サプライヤーなどが含まれます。たとえば、情報セキュリティ 8.7.3 では、組織は実際の状況に応じて属性を追加する必要があります。 、アセットには安全な割り当て属性を追加する必要があります。
8.2.6 構成管理
構成アイテムの種類を定義し、サービスを構成アイテムに分類する必要があります。 構成情報は、サービスの重要性と種類に応じた詳細レベルでログに記録する必要があり、構成情報へのアクセスを制御する必要があります。各構成アイテムの構成情報には次のものが含まれている必要があります。 a) 固有の識別。 b) 構成アイテムのタイプ。 c) 設定項目の説明。 d) 他の設定項目との関係: e) ステータス。 構成情報の整合性を維持するには、構成項目を制御し、構成項目への変更を追跡および監査できる必要があります。構成アイテムへの変更がリリースされた後、構成アイテムを更新する必要があります。 組織は、スケジュールされた間隔で構成情報の正確性を検証する必要があります。逸脱が発見された場合、組織は必要な措置を講じるものとします。 該当する場合、構成情報は他のサービス管理アクティビティに利用できる必要があります。
1. サービス プロセスに基づいて、顧客/ユーザー、サービス組織、サービス カタログ、SLA、関連ドキュメント、サービス、IT システム、資産などの CI タイプを定義できます。 2.CI 属性には通常、次のものが含まれます。 2.1 識別タイプ: 構成アイテムの識別/ラベル (自動的に識別可能な構成アイテム番号/モデル/ライセンス番号/コピー番号)。 2.2 定義クラス: 構成アイテムの分類; 構成アイテムの説明; 2.3 関係クラス: 構成アイテム間の関係: 親子関係、統合関係、関連関係など。構成アイテムと IT コンポーネントの設置環境間の対応関係。 2.4 管理カテゴリ: ステータス、責任部門/責任者 (構成アイテムの所有者、保守管理者、管理者など)、構成アイテムを承認する組織。承認日); 保守サービス期間; 2.5 ユーティリティのカテゴリ: 可用性の容量のインデックス、セキュリティのインデックス。 2.6 構成クラス: 構成をさらに改良することなく、IT コンポーネントの構成 (特定の属性を含む) を、CPU 使用率などの構成項目の属性として使用できます。 3. CI ステータスには、承認されたがまだ起動されていない構成アイテム (運用環境での展開を指します) (構成ライブラリにまだインポートされていません) が含まれます。そのステータスには、開発中、調達中、テスト済み、および承認済みが含まれます。 ; (構成ライブラリ内の) オンライン構成アイテムのステータスには、使用中、非アクティブ化、メンテナンス中 (保留中の変更など) が含まれます。 オフラインおよび削除された構成アイテムのステータスには、削除/削除、リース期限切れ (クラウド サービス) が含まれます。 4. CI は管理されるべきである この条項の目的は、組織が CI の変更を追跡および監査して、CI が管理されていること、および CI 情報がシステムに展開されている物理 CI と一致していることを確認することです。 5. CI 監査の実施要件の例は次のとおりです。 構成項目を定期的に確認して、構成管理データベース内の情報が完全かつ正確であり、タイムリーに更新されていることを確認します。主要な変更の実装後、またはその他の管理要件が実行された後に実行する必要があります。少なくとも年に1回。 構成管理システムのログ情報と監査操作記録を定期的にチェックし、疑わしい状況があればすぐに報告して、構成データベースの運用セキュリティを確保します。構成管理データベース内の情報のサンプリング検査を定期的に組織し、サンプリングですべてをカバーする必要があります。構成アイテムのカテゴリ。サンプリング率は次のとおりです。合計項目数が 10 未満の構成項目の場合、サンプリング率は 50%、合計項目数が 10 ~ 50 個の構成項目の場合、サンプリング率は 20% です。アイテム数が 50 を超える場合、サンプリング率は 10 %wait です。
8.3 関係と合意
8.3.1 一般規定
組織はサプライヤーを次の目的で利用する場合があります。 a) サービスを提供または運営する。 b) サービスコンポーネントを提供または運用する。 c) 組織の SMS でプロセスまたはプロセスの一部を実行します。
1. 組織は、(サービス要件を定義する)外部プロバイダーとサービス契約を締結し、サービス要件を満たすために内部プロバイダーおよび顧客(サプライヤーとして)と文書化された契約書に署名します。 2. 同じ顧客の場合、サプライヤーの数に関係なく、すべてのサプライヤー契約または文書化された契約は最終的に顧客の SLA と一致する必要があります。特定の顧客の SLA の目標指標を分解して、サプライヤーの契約または同意書の目標指標を取得します。 3. 注: サプライヤー管理には完全なライフサイクル プロセスがあります。つまり、サプライヤーの初期評価、サプライヤー アクセス、調達 (選択)、使用、監視、再評価、終了などです。調達前のプロセスは、この規格の範囲。
8.3.2 取引関係の管理
顧客ユーザーおよびサービスのその他の関係者は特定され、記録される必要があります。組織は、顧客関係を管理し、顧客満足度を維持する責任を負う担当者を任命する必要があります。 組織は、顧客およびその他の関係者とのコミュニケーションチャネルを確立する必要があります。コミュニケーションは、サービスが運営されるビジネス環境の変化についての理解を促進し、組織が新しいサービス要件または変更されたサービス要件に対応できるようにする必要があります。 組織は、計画された間隔でサービスパフォーマンスの傾向とサービス結果をレビューするものとします。 組織は、計画された間隔で代表的な顧客サンプルに対してサービスの満足度を測定する必要があります。結果を分析およびレビューして、改善の機会を特定し、報告する必要があります。 閉鎖とサービスに関する苦情は記録され、管理され、報告される必要があります。サービスに関する苦情が通常のチャネルで解決できない場合は、エスカレーションの手段を提供する必要があります。
1. 顧客関係管理の核心は価値です。これは、Win-Win の状況を達成するための、顧客の特定、維持、発展のライフサイクル プロセスにおける顧客価値の特定、維持、発展の長期的かつ継続的な動的な管理を意味します。価値判断には、組織が顧客に提供する価値、組織の価値に対する顧客の貢献が含まれます。 顧客関係管理には、顧客情報の収集と顧客データベースの確立、顧客の分類と主要なアカウント管理の実行、顧客の苦情への適切な対応、忠実な顧客の育成の 3 つの段階が含まれます。 2. ビジネス環境とは、政策、経済、技術、社会文化、顧客、競合他社などの外部環境要因のほか、組織ビジョン、戦略目標、内部組織構造、人事責任、製品などの顧客のビジネス環境を指します。 /サービス、生産ラインの運用、供給 チェーン管理、顧客関係管理、アプリケーション システム、IT インフラストラクチャなどの内部環境要因。 3. サービスパフォーマンス指標を確立するための基礎は、サービスレベル契約のサービス管理目標 6.2、サービス提供 8.2.1、および目標指標 8.3.3 です。 4. サービスに関する苦情は満足度評価の一部です。苦情の提出、受付と記録、処理、確認、終了、報告およびその他の活動を含む、サービスに関する苦情のプロセス全体を管理する専任の担当者が必要です。苦情チャネルは組織のコミュニケーションチャネルの一部である必要があり、通常のチャネルで苦情を解決できない場合は、組織は管理ホットラインなどのエスカレーション方式で苦情を解決するための他のチャネルを提供する必要があります。等
8.3.3 サービスレベル管理
組織と顧客は、提供されるサービスについて合意する必要があります。 組織は、提供されるサービスごとに、文書化されたサービス要件に基づいて 1 つ以上の SLA を確立する必要があります。 SLA には、サービス レベルの目標、ワークロードの制限、および例外を含める必要があります。 組織は、計画された間隔で監視、レビュー、報告を行うものとします。 a) サービスレベル目標に対応するパフォーマンス。 b) SLA のワークロード制限と実際のワークロードのステータスおよび定期的な変化との比較。 サービス レベル目標が達成されていない場合、組織は改善の機会を特定する必要があります。 注: サービスを提供するための組織とその顧客間の契約には、書面による契約、会議での口頭での契約の記録、電子メールでの指示に関する契約、またはサービス利用規約など、さまざまな形式があります。
1. サービスおよび SLA の監視要件は次のとおりです。監視する必要があるサービス項目は、SLA およびサービス カタログに基づいて明確に定義される必要があります。各サービス項目の実装プロセスと主要なアクティビティ(サービスによってサポートされる顧客のビジネス活動)。サービス)を明確にする必要があります。 インシデント作業ログなどのサービス記録、週次レポート、月次顧客満足度レポートなど、実装作業の記録情報を取得する必要があります。 主要なアクティビティについては、次のような情報システム ステータス情報を取得する必要があります。これには、平均値、ピーク値とトラフ値、定期的な物理ステータスを含む、可用性、パフォーマンス、およびセキュリティのシステム構成パラメータが含まれます。 2. 評価指標の目標値: サービス/システムの可用性指標、サービス/システムの容量指標、RTO、RPO など。各タスクの完了率、正解率、適時率など 組織は、収集したモニタリング情報に基づいて評価指標の実際の値を推定し、目標指標と比較し、SLA レビューを実施する必要があります。 レビューのポイントは次のとおりです。サービスモニタリングの結果に基づいてサービスレベルを項目ごとに評価し、SLA を満たしているかどうかを判断し、SLA の評価に基づいて SLA の維持または変更の要件を決定します。結論。 3. レビュー結果を要約してサービス レベル レポートを作成する必要があります。レポートの主な内容は次のとおりです。サービス SA 満足度、顧客満足度。 SLA を満たしていない企業については、サービス カタログとサービス レベルの最適化、ポジションと人材を含むサービス能力の最適化、スキルとサービス プロセスの最適化、サービス プロセスの最適化などの改善措置を提案します。 ; サービス リソースの最適化。その他の改善。
8.3.4 サプライヤーの管理
8.3.4.1 外部サプライヤーの管理 組織は、外部プロバイダーとの関係、契約、およびパフォーマンスの管理に責任を負う担当者を指名するものとします。 組織は、各外部プロバイダーに対して文書化された契約を締結するものとします。契約書には、以下への参照が含まれるか、含まれている必要があります。 a) 外部プロバイダーによって提供または運用されるサービス、サービスコンポーネント、プロセスまたはプロセス部分の範囲。 b) 外部サプライヤーが満たすべき要件。 c) サービスレベル目標またはその他の契約上の義務。 d) 組織および外部プロバイダーの権限と責任。 組織は、外部プロバイダーのサービス レベル目標またはその他の契約上の義務と顧客の SLA との整合性を評価し、特定されたリスクを管理する必要があります。組織は、外部プロバイダーとのインターフェースを定義および管理するものとします。 組織は、計画された間隔で外部プロバイダーのパフォーマンスを監視するものとします。サービス レベル目標またはその他の契約上の義務が満たされていない場合、組織は改善の機会が確実に特定されるようにする必要があります。 組織は、計画された間隔で現在のサービス要件に照らして契約をレビューするものとします。契約変更が承認される前に、SMS およびサービスに対する変更の影響を評価する必要があります。 組織と外部プロバイダーとの間の紛争は文書化され、解決されるまで管理される必要があります。
1. サプライヤーのパフォーマンスは、提供された結果に基づいてパフォーマンス指標を確立し、定期的な再評価、継続的な選択または撤退の基礎として毎日の追跡、監視、評価を実施する必要があります。これは、顧客と署名された SLA (つまり、サービスパフォーマンス指標全体) に基づいており、サプライヤーの責任と成果物を考慮し、構成管理 8.2.6 で確立されたサービス、サービスコンポーネント、CI などの間の依存関係を組み合わせて、サプライヤーの責任と成果物を明確にし、サービス全体における関係者と成果物が決定され、パフォーマンス指標が最終的に決定されます。 2. 外部サプライヤーのリスクの特定は、パフォーマンスの逸脱(顧客 SLA からの逸脱)に基づいて行う必要があります。これには、具体的には次のようなものがあります。外部サプライヤーによって提供される結果。変更によって引き起こされる可能性のあるリスク。これは最終的には直接的な業績逸脱のリスクに反映されます。外部サプライヤーの経営状況、倒産、コンプライアンスなど、外部サプライヤーによって管理されるリスク。 3. 外部サプライヤーとのインターフェースには、担当者間の通信インターフェース、双方の管理システム間のインターフェース (顧客関係管理システム、プロジェクト管理ツールなど)、および運用保守管理ツール (企業が使用する管理ツールなど) が含まれます。双方のインターフェースなど) 4. 両当事者間の紛争、契約変更、その他の問題を解決するために、契約に対する外部サプライヤーの満足度を定期的に確認します。契約のレビューは専門の部門や担当者によって組織され、定期的に実行されるべきであり、契約要件から大きく逸脱する外部サプライヤーに対しては、双方が契約を維持すべきか変更すべきかを明確にする必要があります。 SMS およびサービスに対する契約変更の影響を評価するには、8.5.1.1 の影響ベンチマークを参照する必要があります。たとえば、撤退を希望する外部サプライヤーに対しては、適切な対策を講じる必要があります。サービスの再設計と変換を事前に行う必要があります (8.5)。当事者間の紛争については、契約の規定を履行し、問題を直接解決して解決する必要があります。
8.3.4.2 社内サプライヤーとサプライヤーとしての顧客の管理 組織は、サービス レベルの目標、その他の約束、活動、当事者間のインターフェースを定義するために、各内部サプライヤーまたはサプライヤーとしての顧客と文書化された契約を作成、交渉、維持するものとします。 組織は、計画された間隔で、社内サプライヤーまたはサプライヤーとして機能する顧客のパフォーマンスを監視するものとします。サービス レベル目標またはその他の合意された約束が達成されていない場合、組織は改善の機会が確実に特定されるようにする必要があります。
組織は、サービス レベル目標、その他の約束、活動、インターフェイスを含む契約を内部サプライヤーまたは顧客と締結する必要があります。内部サプライヤーまたはサプライヤーとしての顧客の管理プロセスは、8.3.4.1 の外部サプライヤー管理プロセスを参照できます。 サービスレベル目標およびパフォーマンス指標の確立は、外部サプライヤーのサービスレベル目標、パフォーマンス指標、およびその他の関連コンテンツを参照することができます (8.3.4.1)。 契約の内容構成は、外部サプライヤー契約の関連内容を参照する場合があります (8.3.4.1)。インターフェースの定義と管理は、外部プロバイダーインターフェース(8.3.4.1)に関する内容を参照できます。 組織は、内部サプライヤーまたは顧客のパフォーマンスを定期的に監視および評価して、サービス レベル目標またはその他の合意された約束が満たされているかどうかを判断し、外部サプライヤーに改善を要求する必要があります。
8.4 需要と供給
8.4.1 サービスの予算編成と会計処理
組織は、財務管理ポリシーとプロセスに従って、サービスまたはサービス グループの予算を立て、会計処理する必要があります。 効果的な財務管理とサービスの決定を可能にするためにコストを予算化する必要があります。 組織は、計画された間隔で予算に対する実際のコストを監視および報告し、財務予測を確認してコストを管理するものとします。 注: 多くの組織はサービスに対して料金を請求しますが、すべてではありません。この標準におけるサービスの予算編成と会計には、すべての組織への適用性を確保するために料金が含まれていません。
組織は、サービスのコスト対象とコスト分類を明確にする必要があります。コスト対象には、サービスをサポートする組織のツールと資産 (ソフトウェアとハードウェア)、人員、IT インフラストラクチャ、場所などが含まれます。コスト分類には、直接コストと間接コストが含まれます。コスト オブジェクトがコスト見積もりに含まれるかどうかは、そのオブジェクトが組織に属するかどうかに関係なく、両当事者によって共有され、共同で構築される部分が割り当て可能なコストとなります。 組織は実際のコストを定期的に監視、評価、報告し、予算の有効性を確認する必要があります。
8.4.2 需要管理
計画された間隔で、組織は次のことを行うものとします。 a) サービスに対する現在の需要を判断し、将来の需要を予測する。 b) 需要とサービスの使用状況を監視および報告する 注: 需要管理は、顧客の現在および将来のニーズを理解する責任があります。キャパシティ管理は需要管理と連携して機能し、需要を満たすのに十分な機能を計画および提供します。
1. サービス要件を管理して、組織がサービス要件をタイムリーに取得し、サービス収益を増やすために可能な限り SLA 署名可能なサービスに変換できるようにします。 2. サービス ニーズは顧客のビジネスの変化から生じ、需要の獲得がサービス ライフ サイクル プロセスの開始点となります。需要管理の鍵は、特定の顧客に対する需要分析モデルを確立することです。モデルには主に次の内容が含まれます。 入力: 以下のような顧客のビジネス、顧客の IT システムおよびサービスを含みます。 —顧客のビジネス: 顧客のコアビジネスとサポートビジネスを区別し、コアビジネスの現状と発展傾向、特にビジネスキャパシティの変化傾向に焦点を当てる必要があります。 、ビジネスキャパシティのピーク期間と特別な日(ダブルイレブンやインターネットビジネスのその他の日など)。 1. お客様のITシステム:アップグレード、スクラップ、リソース容量(有効利用率など)、新技術の採用、新システムの立ち上げ、アプリケーションのクラウドコンピューティングへの移行など。 1 対 1 のサービス: 実行中のサービス (顧客サービス カタログ内のサービス) のステータス (サービスの有効な使用または消費、SLA によるサービスの満足度、サービス価格の顧客の評価を含む)、サービスの変更リクエスト、サービス プロバイダーの顧客の評価と変更、など。 アウトプット: 以下のような顧客のビジネス、顧客の IT システムおよびサービスが含まれます。 1. 顧客のビジネス: 新しいビジネス能力 (ピーク時および特別日のビジネス能力を含む) およびコンピューティング能力またはビジネス サービスの需要。 お客様のITシステム:機能、パフォーマンス、容量などの新規追加および変更、および対応する技術サービス要件。 One to One サービス: 撤退した顧客サービスプロバイダー、顧客の中核事業運営パフォーマンス、顧客 SLA 満足度、サービスコストパフォーマンスに関する顧客評価、および新規サービス要件と変更されたサービス要件。 新しいサービス要件または変更されたサービス要件は、8.2.2 を通じて特定および文書化できます。 3. 需要管理はキャパシティ管理と密接に関係しており、顧客システムのリソースキャパシティの変化により、ビジネス サービス (コンピューティング能力) および技術サービス (検査、障害処理など) の需要が発生する可能性があります。ここでのリソース容量は、容量管理にも適用されます。 需要管理は財務管理に関連する必要があり、組織管理が財務に対する需要の影響を予測および管理できるように、需要を財務データで定量化する必要があります。 組織は、顧客の既存のテスト ツールを展開または採用し、需要分析モデルの入力データを取得し、定期的に需要分析を実施し、顧客の既存のサービス消費量と新しいサービス ニーズに焦点を当てた需要分析レポートを作成する必要があります。 4. 必要に応じて、組織は SMS のパフォーマンス指標として需要換算率 (正式な SI、A に換算) を使用できます。
8.4.3 キャパシティ管理(またはキャパシティ管理)
人員、技術、情報、財務リソースの能力要件は、サービスとパフォーマンスの要件を考慮して決定され、文書化され、維持される必要があります。以下を含む組織の対応能力を計画します。 a) サービスのニーズに基づく現在の機能と予測される機能。 b) 合意されたサービス レベル目標、サービス可用性、およびサービス継続要件に対する予想される影響。 c) 能力の変化の期間と閾値。 組織は、合意された容量およびパフォーマンス要件を満たす十分な容量を提供するものとします。組織は、機能の使用状況を監視し、機能とパフォーマンスのデータを分析し、改善の機会を特定する必要があります。 注:容量はキャパシティー、英語:capacityとも呼ばれます。
1. 容量要件のソースを明確にし、リソース容量要件を決定、記録、維持します。キャパシティ要件のソースはサービス要件とパフォーマンス要件であり、リソースには人的、技術的、情報、財務の 4 種類のリソースが含まれます。 2. 顧客のビジネス運営を検討するとき、組織は、ビジネス能力、サービス能力、リソース能力という 3 つのレベルの能力に注意を払う必要があります。組織のコストは、最終的には人的資源、技術、情報、リソースの 4 つのリソースの消費に反映されます。財源。 3. キャパシティ プランニングには、キャパシティの予測、予測されたキャパシティの予想される影響、キャパシティ変更の時間スケールとしきい値が含まれます。 4. 時間スケールとは、特定の物理プロセスを完了するのにかかる時間の平均測定値を指します。一般に、物理プロセスの進化が遅いほど、その時間スケールは長くなります。物理プロセスに関与する空間範囲が広くなるほど、その時間スケールは長くなります。サービス容量の変化の時間は、サービス容量の変化が安定しており、時間スケールが長い場合、リソース容量の変化は小さく、予測モデルは単純であるとみなすことができます。逆に、予測モデルは複雑であり、予測精度は比較的低いです。つまり、時間スケールが小さいということは、サービス容量が大きく変化することを意味する。サービス容量の変更のタイミングを決定する要因には、次のものが含まれます。 1) ピークと谷の交互周波数や曲率など、顧客のビジネス能力ラインの振動の程度。 2) 顧客のビジネスキャパシティのピーク値、トラフ値、通常値、およびそれらに対応する時間帯 (たとえば、午前 9 時から 11 時までがピーク時間帯)。 3) サービスコンポーネントの負荷分散。 5. キャパシティ計画に従ってサービスの展開が完了した後、キャパシティがサービスのキャパシティとパフォーマンスの要件を満たしているかどうかを確認するために、監視と分析の措置を講じる必要があります。逸脱がある場合は、改善策を提案する必要があります。 容量監視のコンテンツには、次のようなコンピューティング リソース、伝送リソース、ストレージ リソースが含まれます。 1. コンピューティング リソース: メモリ、CPU などの有効利用率やタイムリーな応答率などのパフォーマンス指標。 2. 送信リソース: 帯域幅の有効利用率と、QoS や遅延などのパフォーマンス指標。 3. ストレージ リソース: ストレージ スペースの有効利用やタイムリーな応答率などのパフォーマンス指標。 監視データを分析してアラーム(容量不足によるパフォーマンス障害など)を生成するには、アラームの基準となる容量のしきい値を設定する必要があります。
8.5 サービスの設計、構築、変革
8.5.1 変更管理
8.5.1.1 管理戦略の変更 以下を決定するために、変更管理戦略を確立し、文書化する必要があります。 a) 変更管理の管理下にあるサービスコンポーネントおよびその他の事項。 b) 緊急の変更を含む変更カテゴリーとその管理方法。 c) 顧客またはサービスに重大な潜在的な影響を与える可能性のある変更を特定するための基準。
1. 組織は変更管理ポリシーを明確にし、正式な文書を策定する必要があります。変更管理ポリシーには、変更管理の範囲に含まれる資産 (または CI) およびその他の要素 (SLA など)、変更の種類と破棄プロセス、および変更の影響の評価基準が含まれます。 変更管理制御の対象となるサービス コンポーネントには、以下で説明するように、サービスをサポートするすべての資産およびその他の要素が含まれている必要があります。 ——お客様の業務運営を支える資産:主に情報システム、計算機室等の物理設備を指します。 ——顧客の業務運営をサポートする組織の資産: 組織が技術サービスのみを提供する場合、組織が顧客の業務運営をサポートする資産も提供する場合 (前の項目を参照)、これらの資産はサービス監視および管理ツールを指します。変更管理制御の対象となる。 ——サプライヤーの資産: サプライヤーが提供するサービス、サービス コンポーネント、機能に応じて、サービスの監視および管理ツールを提供したり、サービス コンポーネントを組織に提供したり、組織がそれらを展開して顧客の業務運営をサポートしたりする場合があります。情報システムでは、これらの資産は変更管理制御の対象となる必要があります。 ——変更の種類: 変更は通常、情報資産の種類と、インストールと展開、アップグレード、パッチ、変換、移行、廃棄などの技術的アクティビティの 2 つの側面に基づいて分類されます。 2. 変更レベルは、通常、変更の影響度に基づく、より厳格な変更の分類です。変更のレベルを評価するための基本的な要素は、キャッチアップ (時間が基準) と影響度の分析です。影響の程度は、次の要素を総合的に考慮する必要があります。 ——システムまたはサービスのイベント: 効率の低下、中断、リークなど。 ——国や社会が関与するシステムやサービスは、個人の安全と目に見えない影響に焦点を当て、漏洩を優先する必要があります。 ——リアルタイム性の高いシステムやサービスは、主に財務、顧客、生産能力、評判、ブランドなどへの影響に焦点を当て、中断イベントを優先する必要があります。 ——社内でのみ使用されるシステムまたはサービスの場合、効率低下イベント、主に生産能力への影響を優先する必要があります。 ——顧客が使用するシステムやサービスは、顧客や生産能力などへの影響を考慮し、中断イベントを優先する必要があります。 3. 変更評価ルールに従って変更レベルを設定します。変更評価ルールには少なくとも以下が含まれます。 標準的な変更: 成熟した運用、高い再現性、最小限の影響による変更。 一般的な変更: システムに一定の影響を及ぼし、レビューに IT マネージャーとビジネス マネージャーの参加が必要な変更。 重要な変更: 最高幹部によるレビューが必要な変更。 緊急の変更: 変更時間の要件は緊急であり、変更の成功率と完了の適時性に重点が置かれます。 4. 変更の実行プロセスを追跡するには、新規、レビュー済み、計画中、レビュー中、レビュー済み、スケジュール済み、実装済み、待機中、変更済み、完了、終了などの変更ステータスが明確である必要があります。
8.5.1.2 変更管理の開始 サービスの追加、削除、または転送の提案を含む変更リクエストは記録され、分類される必要があります。 組織は、以下の状況に対して 8.5.2 のサービス設計と変換を採用する必要があります。 a) 変更管理戦略に従って顧客または他のサービスに重大な影響を与える可能性のある新しいサービス。 b) 変更管理戦略に従って、顧客または他のサービスに重大な影響を与える可能性のあるサービスの変更。 c) 変更管理戦略に従ってサービス設計と変革によって管理される必要がある変更のカテゴリ。 d) オフラインでのサービス。 e) 既存のサービスを組織から顧客またはその他の関係者に移転する。 f) 既存のサービスを顧客またはその他の関係者から組織に移管します。 8.5.2 の範囲内の新しいサービスまたは変更されたサービスは、8.5.1.3 の変更管理アクティビティを通じて評価、承認、スケジュール、およびレビューされる必要があります。 8.5.2 を通じて管理されない変更リクエストは、8.5.1.3 の変更管理アクティビティを通じて管理されます。
1. サービスのリクエストを追加すると新しいサービスが生成される場合があり、サービスの削除または転送はカスタマー サービス カタログと SLA に大きな影響を与えるため、カスタマー サービス カタログと SLA の変更が必要になる場合があります。このような場合、サービスの再設計と変更が必要になることがあります。変換された。 2. サービスの追加、削除、または転送のソースは Service Demand Management 8.4.2 であり、特定の条件を満たし、組織の責任または契約の範囲内にあるサービス変更リクエストを形成し、サービス設計と署名が必要です。最後に、顧客のビジネス システムに展開および実装する必要があります。 3. 資産または CI およびその他の要因の変化には、以下が含まれます。 a. 顧客の業務運営の変更に伴うサービスの変更には、サービスの設計と変換が必要です。 b. 顧客の IT インフラストラクチャの変更によりサービスが変更され、サービスの設計と変換が必要になります。 c. 顧客のビジネス環境の変化 (4.1、8.3.2 を参照) は、顧客の業務運営の変化と顧客の IT インフラストラクチャの変化につながり、サービスの設計と変換が必要になります。
8.5.1.3 変更管理アクティビティ 組織と関係者は、変更リクエストの承認と優先順位付けに関して決定を下す必要があります。意思決定では、リスク、商業的利益、実現可能性、財務上の影響を考慮する必要があります。決定では、変更による以下への潜在的な影響も考慮する必要があります。 a) 既存のサービス。 b) 顧客、ユーザー、その他の関係者。 c) この規格で要求されるポリシーと計画。 d) 容量、サービスの可用性、サービスの継続性、および情報セキュリティ。 e) その他の変更リクエスト、リリース、展開計画。 承認された変更は準備、検証され、可能な場合はテストされる必要があります。承認された変更に関する推奨される展開日およびその他の展開の詳細は、関係者に通知される必要があります。 失敗した変更のロールバックまたは修復を計画し、可能な場合はテストする必要があります。失敗した変更は調査され、合意された措置を講じる必要があります。 組織は変更の有効性を検討し、関係者全員と合意した措置を講じるものとします。 傾向を特定するには、変更要求レコードを計画された間隔で分析する必要があります。分析から得られた結果と結論は文書化してレビューし、改善の機会を特定する必要があります。
1. 変更リクエストは承認され、優先順位が付けられる必要があります。承認と優先順位の決定要因には、リスク、ビジネス上の利益、実現可能性、財務上の影響が含まれます。 2. 変更要求は、変更の開始者の基本情報、変更の対象と範囲、変更の提案時期、変更の内容、変更の理由、変更のリスク、変更の種類を含む標準化された文書 (RFC フォームなど) に形成される必要があります。 、変更レベル、変更ステータス、変更計画、変更障害対応計画(ロールバック、リカバリ、緊急時などの計画)、コスト予算など、その他の必要な要素。 3. 変更承認組織には以下が含まれる場合があります: 変更管理者: 変更要求の事前審査を実施、変更マネージャー: 一般的な変更を承認、変更管理委員会: 緊急または重大な変更を承認。上記の組織は通常、サービスプロバイダー、顧客、サプライヤー、その他の必要な組織を必要とします。人員構成。 変更(特に大きな変更)を承認するために必要な入力内容には、変更要求フォーム、事前レビューと受諾意見、変更実施計画、変更障害対応計画(ロールバック計画、緊急是正措置など)、人的組織構造、責任の紹介、技術的な実現可能性の説明、解決すべき問題または利点の説明、コスト予算の説明、リスクの説明、ビジネスへの影響および廃棄措置。 4. 変更テストの要件は次のとおりです。 ビルドされた変更、実装計画、フォールバック計画、バックアップ計画、緊急時対応計画をテストする必要があります。 変更テスト計画は、テストの内容、担当者、タイムスケジュールなどに基づいて作成する必要があります。主な内容には、単体テスト、結合テスト、回帰テストなどのテストの種類、テストケースの設計、およびテストの内容が含まれます。テスト環境の構築、テスト記録テンプレート、テスト担当者の組織および責任。 特別なテスト環境 (準本番環境など) を構築する必要があり、本番環境での変更テストは禁止されています。 テスト実行プロセス中に次の作業を実行する必要があります: テストの問題の発見と追跡、テストの結果。 5. 検証後に承認された変更については、実施計画を策定し、顧客、サプライヤー、その他の関係者に通知する必要があります。実装計画の主な内容には、実装の内容と範囲、構築された変更とロールバックまたは修復計画、実装のタスクと担当者の配置、およびその他の計画が含まれます。必要な要素。 6. 変更に関連する記録と報告書を定期的に収集して整理し、変更の実施に関する統計を作成し、開発傾向を特定する必要があります。主な内容は次のとおりです。 ——数量: 変更リクエストの合計、フィルターされた変更リクエスト、承認された変更リクエスト、成功/失敗した変更、緊急変更、およびさまざまなタイプ/レベルの変更の数 (標準的な変更の数を含む)。 ——時間: リクエストからクローズまでの平均処理時間と各リンクの平均時間 (平均承認時間など)。 ——配分: 資産/CI の数量配分、コスト範囲の数量配分。
8.5.2 サービスの設計と変換
8.5.2.1 新規または変更されたサービスの計画 計画は、8.2.2 で特定された新規または変更されたサービスのサービス要件に基づいている必要があり、次の内容への参照が含まれるか、含まれている必要があります。 a) 設計、建設、変換活動に対する権限と責任。 b) スケジュールに従って組織またはその他の関係者によって実行される活動。 c) 人的、技術的、情報的、および財政的資源。 d) 他のサービスへの依存。 e) 新しいサービスまたは変更されたサービスに必要なテスト。 f) サービスの受け入れ基準。 g) 新しいサービスまたは変更されたサービスの提供によって期待される結果の測定可能な説明。 h) SMS、その他のサービス、プランの変更、顧客、ユーザー、その他の関係者への影響。 サービスをオフラインにする場合、計画には、オフライン サービスの日付、データ、サービス コンポーネント、ドキュメント、その他のアクティビティのアーカイブ、処理、送信も含める必要があります。 サービスを移転する場合、計画には、サービス移転の日付、データ、文書、知識、サービス コンポーネントの提供と引き継ぎも含める必要があります。 新しいサービスまたは変更されたサービスの影響を受ける CI は、構成管理を通じて管理する必要があります。
1. 計画作業では、背景、原則、目標、実施計画および計画に加えて、次の内容も含めて計画報告書を作成する必要があります。 a) サービスの実施プロセス全体における組織と責任を確立する必要があります。組織内の役職または人員には、サービス企画に携わる担当者、サービス設計担当者、サービス構築担当者、サービス変換担当者などが含まれます。これらの担当者は区別される必要があります。これらの担当者は、組織、顧客、またはサプライヤーに属する担当者です。顧客またはサプライヤーの担当者は、8.2.3 および 8.3.4 の要件に従って管理される必要があります。 b) 組織およびその他の関係者のタスクと作業プロセスを明確にし、サービス実現の全体的な進捗状況を把握するための全体的な作業計画が必要であるだけでなく、個別の作業計画の作成も必要です。組織、顧客、サプライヤー、および最終調整のためのサービス実装を一貫して完了します。 c) サービスの実装に必要なリソースを明確にし、これは組織のコスト要素でもあり、リソースのコストを定量化し、コストの消費を制御する必要があります。これらのコストには、サプライヤーの成果物 (サービス、サービス コンポーネント、サービス プロセス) を購入するコストと、サービス実装への顧客の参加コストが含まれます。 d) 依存関係のある他のサービスが変更される可能性があると判断され、その場合、関連するタスクとコストが発生します。関連するタスクはその人の作業計画に含める必要があり、関連するコストはサービスコストに含める必要があります。 e) 作業計画には、必要なテストの手配が含まれている必要があり、テストの費用はサービス費用に含まれている必要があります。 f) 導入後にサービスが顧客の要件を満たす必要があるかどうか。受け入れ基準には次のものが含まれます。 —— 両当事者 (組織と顧客) が署名した SLA 要件を満たします。 ——両当事者のコスト財務管理要件 8.4.1 を満たす。 ——法令およびその他必要な遵守事項を遵守します。 g) サービスの目標または期待される結果が、受け入れ基準の運用性を保証するために測定可能であることを強調します。 h) サービス実践におけるリスク管理と制御 8.5.1.1 および 8.5.1.3 の要件に従って、影響が許容できない場合、SMS、その他のサービス、プラン変更、顧客、ユーザー、およびその他の関係者への影響を評価できます。 、リスク処理措置を講じる必要があります。 2. 新規または変更されたサービスの影響を受けるものについては、新規または変更されたサービスの影響を受ける Ci は、構成管理 8.2.6 に従って管理される必要があります。その実装には、変更管理と構成管理の間の接続を確立する必要があります。具体的には次のようなものです。 ——変更管理で CI または影響を受ける CI を特定してラベルを付け、残りの構成ライブラリ内の CI に一貫性があることを確認します。 ——変更または影響を受ける CI を追跡し、変更の実装が完了したら、最終的な CI 情報を構成管理担当者に渡します。 ——渡されたCI情報に従って、構成ライブラリ内の該当するCI情報を変更し、検証・比較後、CI更新を完了します。
8.5.2.2 設計 新規または変更されたサービスは、8.2.2 で特定されたサービス要件を満たすように設計および文書化する必要があります。設計には次の関連要素を含める必要があります。 a) 新しいサービスまたは変更されたサービスの提供に関与するすべての当事者の権利と責任。 b) 人的、技術的、情報的、および財政的資源の変更要求。 c) 対応する教育、トレーニング、および経験の要件。 d) 新規または変更された SLA、契約、およびサポート サービスに関するその他の文書化された契約。 e) 新規または変更されたポリシー、計画、プロセス、手順、措置、知識を含む SMS の変更。 f) 他のサービスへの影響。 g) サービスカタログの更新。
1. 組織は、サービス計画の結果が実現可能かつ実装可能であることを保証するために、サービス計画に基づいてサービス設計作業を実行する必要があります。 サービス計画は、構築タスクのフレームワーク要件を設定することに重点を置いています。これは、管理のための青写真形式の計画です。一方、サービス設計は、実装するサービスの重要性と規模に基づいて明確にする必要があります。予備設計、詳細設計、物理的な配置を伴う施工図の設計(コンピュータ室設備の建設など)。 2. d)項では、新規または変更されたSLA、契約、およびその他の文書化された合意要件を満たすための設計計画のレビューを要求しており、これはより具体的な受け入れ基準です。 条項 e) は、SMS に関するポリシー、計画、プロセス、手順、措置、知識の新規または変更の確立を伴う SMS 変更のリスクを強調しており、適切な対応策が講じられるべきであるとしています。 サービスを設計したら、構築して移行する前にカスタマー サービス カタログを更新する必要があります。
8.5.2.3 構築と変換 新しいサービスまたは変更されたサービスを確立し、テストして、サービス要件への準拠、文書化された設計への準拠、および合意されたサービス受け入れ基準への準拠を検証する必要があります。サービスの受け入れ基準が満たされていない場合、組織と関係者は必要なアクションと展開を決定する必要があります。 リリースおよび展開管理は、承認された新しいサービスまたは変更されたサービスを運用環境に展開するために使用する必要があります。転換活動の完了後、組織は期待される結果と比較して転換の結果を利害関係者に報告する必要があります。
1. 組織は、新規または変更されたサービスを構築し、関連する標準 (サービス要件 (SA など)、設計ソリューション、およびサービス受け入れ基準を含む) が満たされているかどうかを確認するためのテスト作業を完了する必要があります。 2. サービス構築の結果は以下の種類で表示されます。 a) お客様の業務運営をサポートするソフトウェアパッケージ。 b) 顧客の業務運営をサポートする統合された設備と施設。 c) 最初の 2 つの項目を含むソフトウェアとハードウェアの統合の組み合わせ。 ——IaaS、PaaS、SaaSなどのクラウドサービス。 ——データストレージやデータ分析など、お客様の業務運営を支援するデータサービス。 ——顧客のビジネス システムのインストール、展開、アップグレード、強化/パッチ適用、セキュリティ インシデントまたは障害の処理、構成操作、検査と検査、評価と評価、監査などの技術活動/技術サービス。 ——その他、映像・音声サービス等 3. 構築されたサービスには、次のように、サービス結果のタイプと一致するビジネス環境要因も含める必要があります。 ——物理的環境: コンピュータ室の空調、電気、キャビネット、統合配線およびその他の機器および設備、空間レイアウト、物理的接続などを含みます。 ——ネットワーク環境: ネットワーク アーキテクチャとコア機器、ネットワークの物理トポロジと論理トポロジ (ネットワーク プロトコルやポートなど)。 ——コンピューティング環境: 物理サーバーまたは仮想サーバー、ストレージなどの構成と接続。 ——セキュリティ環境:ネットワーク境界、セキュリティ機器などの設定と接続。 ——管理環境: 人材と組織の要件、技術活動、サービスプロセスなどの関係。 つまり、ソフトウェアパッケージを提供するだけでは顧客が求める「サービス」ではなく、ソフトウェアパッケージの動作環境も考慮してサービス設計を行う必要があります。 4. テストは、導入前のテストです。テスト環境は、本番環境とできるだけ似たものを構築する必要があります。たとえば、多くの金融機関では、「準本番環境」を構築しています。これは実稼働環境と似ています。テスト環境を構築する場合は、前述のビジネス環境要因を考慮して、サービス要件 (SLA など)、設計計画、サービス受け入れ基準などを考慮する必要があります。 5. 結果をリリースおよび展開した後、組織は、期待される結果(計画における目標と青写真、設計計画における結果、サービス構築における結果タイプなど)と実際のサービスの展開および運用との対応関係を確立し、決定を提供する必要があります。適合度を確認し、顧客、サプライヤー、規制当局などに提出します。
8.5.3 リリースおよび展開の管理
組織は、緊急リリース、頻度、管理方法などのリリースの種類を定義する必要があります。 組織は、新規または変更されたサービスおよびサービス コンポーネントの運用環境への展開を計画する必要があります。計画は変更管理と調整し、関連する変更リクエスト、既知のバグ、またはリリースによって解決された問題への参照を含める必要があります。計画には、各リリースの導入日、成果物、導入方法を含める必要があります。 リリースは、文書化された受け入れ基準に照らして検証され、展開前に承認される必要があります。受け入れ基準が満たされていない場合、組織と関係者は必要なアクションと展開を決定する必要があります。 リリースをランタイム環境に展開する前に、影響を受ける CI のベースラインを確立する必要があります。リリースがランタイム環境にデプロイされるときは、サービスとサービス コンポーネントの整合性を維持する必要があります。 リリースの成功または失敗は監視および分析する必要があります。測定には、展開リリース後のリリース関連イベントを含める必要があります。分析から得られた結果と結論は文書化され、改善の機会を特定するためにレビューされる必要があります。 リリースの成功または失敗および将来のリリース日に関する情報は、必要に応じて他のサービス管理アクティビティに提供される必要があります。
1. さまざまなレベルに応じて、次の 3 つのカテゴリに分類できます。 1) メジャー リリース: 新しいハードウェアとソフトウェアの大規模な展開。通常、主要な機能強化が伴います。このリリースでは通常、複数の既知のバグが削除され、一時的な回避策と一時的な修正が含まれています。実際には、多くの組織はメジャー リリースを緊急リリースとして扱います。 2) 小規模なソフトウェア リリースとハードウェア アップグレード: このタイプのリリースは通常、いくつかの小規模な改善と既知のバグの修正を指します。一部は緊急修正として以前に実装されていた可能性がありますが、現在はリリースに統合されています。このリリースでは、すべてのテストの開始点である「以前の信頼された状態」も確実に更新されます。 3) 緊急修正: 通常、問題または既知のエラーを一時的に修正するために使用されます。 2. リリースの規模に応じて、次のように分類できます。 1) 緊急リリース: 既知のエラーに対する少数の修正と迅速に実装された解決策。 2) 小規模リリース: 一定数の改善と既知のバグの修正 3) 大規模リリース: 通常、これは新しいソフトウェアとハードウェアの最初のリリース、または既存のアーキテクチャの機能に対する大幅な改善です。 3. リリース パッケージの完全性に応じて、リリースは次のように分割できます。 1) フルリリース: 変更されていない部分を含むプログラムの完全なセットをリリースすることを指します。 2) デルタ リリース: リリースに含まれる変更の数が少ない場合は、デルタ リリースを使用します。 3) パッケージ リリース: 相互に依存し関連する一連のソフトウェアのリリース。 4. リリースが失敗するか成功するかを判断する基準は次のとおりです。 1) 機能、パフォーマンス、セキュリティなどの顧客サービスの目標またはサービス要件を満たすために公開します。 2) リリースは顧客のビジネス システムの IT アーキテクチャと一致しています。 3) リリースおよびその他のコンポーネント (顧客の業務運営をサポートする) のステータスが正常であり、機能/パフォーマンス/セキュリティのパラメータが期待値の範囲内にある。 4) リリースは、必要な接続または関連するサービス コンポーネントと一致します (関係、8.2.5 構成管理を参照)。 5) リリースおよびその他のコンポーネントの有効実行時間は、契約要件に準拠しています。 5. 監視コンテンツには次のものが含まれます。 1) サービスおよびビジネス システムのセキュリティ指標 (データ完全性チェック、暗号化など)、可用性 (サービス可用性 99.9% など)、および継続性 (サービス RPO、RTO など)。 2) リリースおよびその他のコンポーネント(お客様の業務運営をサポートする)のステータス、機能/パフォーマンス/セキュリティパラメータ、CPU/メモリ/ストレージ/帯域幅など。 3) システム障害、セキュリティインシデント、中断等。 4) その他の必須パラメータ。 6. 導入が完了したら、有効性レビューを実施し、次のような改善措置を講じる必要があります。 1) リリースおよび導入の実施プロセス(障害対応を含む)および情報システムの監視データを要約し、それに応じてリリースを分析し、最終的にリリースの成功または失敗の結果を取得し、リリースおよび導入レポートを作成します。該当する広場に提出してください。 2) 失敗または成功したリリースをレビューし、成功または失敗の理由を分析、判断、確認し、失敗したリリースに対する改善責任を明確にし、ニーズが満たされるまで改善要件を提示します。
8.6 決済と履行
8.6.1 イベント管理 イベントは次のことを行う必要があります。 a) 記録および機密扱いとされる。 b) 影響と緊急性に基づいて優先順位を付ける。 c) ニーズに基づいてアップグレードする。 d) 解決する。 e) 閉じます。 インシデント記録は、講じられた措置に基づいて速やかに更新される必要があります。 組織は重要なイベントを特定するための基準を決定する必要があります。重大なインシデントは文書化された手順に従って分類および管理される必要があります。重大なインシデントは経営トップに報告される必要があります。組織は、重大なインシデントごとに管理責任者を任命する必要があります。インシデントが解決したら、重大なインシデントを報告し、レビューして改善の機会を特定する必要があります。
1. イベントの抽出、記録、分析と委任、処理、エスカレーション、解決と終了などを含むイベント処理プロセスを管理します。 2. 内部イベントの原因またはメカニズム: 1) 故障:ソフトウェア、ハードウェア、機器、設備等の機能上の故障。 2) 誤操作: 担当者による意図的または非意図的な操作は、システムの動作に影響を与えます。 3) サプライヤー:サプライヤーの製品やサービスの提供等の中断を指します。 4) 情報セキュリティインシデント:有害なプログラム、ネットワーク攻撃、情報破壊、情報コンテンツの危害などを含みます。 5) 物理的事象: 設備や施設の構造的損傷および老朽化を指します。 6) サーバー IP 設定エラーなどの設定エラー。 外部イベントには、主に、情報システムの運用に大きな影響を与える次のようなイベントが含まれます。 1) 公共の出来事: 感染症、テロ攻撃。 2) 天災:地震、洪水、火災等 3. イベントレベルの判定条件は以下のとおりです。 1) 事象のレベルを評価するための基本的な要素は、緊急性 (時間が基準) と影響度です。影響度の分析では、以下の要素を総合的に考慮する必要があります。 システムまたはサービスのイベント: 効率の低下、中断、リークなど。 事件の具体的な影響: 財務、市場、顧客、生産能力、個人の安全などの観点から国、社会、組織に与える影響。 事件の無形の影響: 社会秩序、組織の評判やブランドなど。 2) 緊急対応が必要なイベントと、日常の手順に従って段階的に実施される一般イベントは、影響の程度に応じて区別されるべきであり、前者については、対応レベルに応じて特別な緊急計画が策定され、処理される必要がある。 3) 一般的なインシデントは処理時間が厳しいため緊急とみなされますが、緊急インシデントは緊急対応を必要としない場合があります。 4) 影響度に応じてイベントレベルを4段階に分けます。 非常に大きなイベント(レベル I)、重大なイベント(レベル III)、一般的なイベント(レベル IV)。 4. イベントステータスは、送信済み、割り当て保留中、割り当て済み、保留中、処理中、保留中、解決済み、イベント終了など、実際の処理プロセスに従って設定する必要があります。 5. インシデントのアップグレードには、以下に詳述するように、テクノロジー/機能のアップグレードと構造/管理のアップグレードが含まれます。 1) 次のイベント処理シナリオに直面した場合は、管理アップグレードを実装する必要があります。 権限不足など管理責任の範囲を超える行為 既存のリソースと機能を考慮した制限時間を超過した場合。 複数の組織に属するシステムの結合部分。 必要なリソースとコストが予想範囲を超えている。 SLA の範囲を超えています。 管理レベルが不十分なため、インシデント処理が失敗しました。 2) 次のイベント処理シナリオに直面した場合は、技術的なアップグレードを実装する必要があります。 インシデントを解決するスキルを持っていない タスクが不適切に割り当てられた場合、割り当てられた担当者はインシデントを解決するスキルを持っていません。 スキル不足などでインシデントが予定時間内に解決できず、効率が低下する。 スキル不足によりインシデント処理に失敗した。 3) 各事件の処理プロセスは完全に記録され、記録は適時に更新される必要があります。イベント レコードの主な内容は次のとおりです。 イベント要求/開始者の基本情報(名前、位置、連絡先情報)、影響を受ける可能性のあるイベントおよびイベントの種類、イベントの検出および報告時間。完了時間; イベントのステータス; イベント処理のアップグレード; 6. 重大インシデントの処理について、評価基準、分類と管理、報告、管理責任者などの要件をより厳格化する。 非常に重大な事象:特に重要な情報システムに特に重大なシステム損失を引き起こしたり、特に重大な社会的影響を及ぼしたりするなど、特に重大な影響や損害を引き起こす可能性のある事象を指します。 重大なイベント: 重大なイベントとは、特に重要な情報システムに重大なシステム損失を引き起こす、または重大な社会的影響をもたらす、重要な情報システムに特に重大なシステム損失を引き起こすなど、重大な影響または損害を引き起こす可能性のあるイベントを指します。 重大なイベント: より深刻な影響または損害を引き起こす可能性のある情報セキュリティ インシデントを指します。これには次の状況が含まれます。特に重要な情報システムに重大なシステム損失が発生する、または重要な情報システムに重大なシステム損失が発生する、一般の情報システムに特に重大な損失が発生するシステムに損失が発生し、より大きな社会的影響を及ぼします。 一般インシデント:上記の条件を満たさない情報セキュリティインシデントを指します。 重大なインシデントの発生と対応については、インシデントのレベル、影響範囲、対応結果、原因分析、対応結果、報告内容が経営トップに報告されます。システムの復旧状況、調査と説明責任の状況、経験と改善の概要など。
8.6.2 サービスリクエストの管理 サービス リクエストは次のことを行う必要があります。 a) 記録および機密扱いとされる。 b) 優先順位の分類。 c) パフォーマンス。 d) 閉じます。 サービス リクエストの記録は、実行されたアクションに従って直ちに更新される必要があります。 サービス リクエストの履行に関する指示は、サービス リクエストの履行に関与する担当者に提供される必要があります。
——リクエストの抽出、記録、分析と委任、処理、解決と終了などを含むサービスリクエストの処理プロセスを管理します。サービス リクエストとは、エンド ユーザーのパスワードの変更やオフィス ソフトウェアのインストールなどの、T システムへの小さな変更の実装を指します。これらの変更は、リスクが低く、頻繁で、低コストです。 ——組織は、実際の状況に基づいてサービス リクエストをイベントの一種として扱い、イベント管理プロセスを参照して、独立したサービス リクエスト解決プロセスを確立する必要があります。 ——組織は、セルフサービス デスク、トレーニング、オンライン文書共有、プッシュ (電子メール送信など) などを通じて、サービス リクエストの履行に関与する担当者に運用ガイダンスを提供できます。
8.6.3 問題管理 組織はインシデントのデータと傾向を分析して問題を特定する必要があります。組織は根本原因分析を実施し、インシデントの発生または再発を防ぐ可能性のある潜在的なアクションを特定する必要があります。 質問は次のとおりです。 a) 記録および機密扱いとされる。 b) 優先順位の分類。 c) ニーズに基づいてアップグレードする。 d) 可能な限り解決する。 e) 閉じます。 問題記録は、講じられた措置に基づいて速やかに更新される必要があります。問題を解決するために必要な変更は、変更管理ポリシーに従って管理する必要があります。 根本原因は特定されたものの、問題が完全に解決されていない場合、組織はサービスに対する問題の影響を軽減または排除するための対策を特定する必要があります。既知のエラーはログに記録される必要があります。必要に応じて、他のサービス管理アクティビティに既知のエラーと問題解決に関する最新情報を提供する必要があります。 問題解決の有効性は、計画された間隔で監視、レビュー、報告される必要があります。
1. 根本原因を見つけられないことを問題と呼び、根本原因を見つけることを既知のエラーと呼びます。 2. イベント発生時にシステム動作を迅速に復元するための根本的な解決策がある場合は、この解決策を直接採用できます。つまり、イベント処理が既知のエラー処理になります。 3. 問題の識別と提起、診断と解決策、処理、終了、および問題の分類、優先順位、エスカレーションなどを含む問題処理プロセスを管理します。 4. 問題の特定と特定に役立つように、通常は次のような問題の原因を明確にします。 1) 繰り返されるイベント。 2) 重大なインシデントの徹底した解決。 3) イベントを既存の問題や既知のエラーと関連付けることはできません。 4) データの傾向分析に基づいて発見および提起された課題。 5) ユーザーの IT インフラストラクチャの監視と検査を通じて発見された潜在的なリスクについては、議論と根本原因の分析が必要です。 5. 問題管理の有効性を監視、レビュー、報告します。問題処理プロセスを追跡および監視し、次のデータを収集します。 1) 提起された問題の総数と既知のエラーの数。 2) 一時的な解決策と永続的な解決策を含む、解決された問題の数。 3) 問題や既知のエラーを含む未解決の問題の数。 4) 問題の分類と解決済みまたは未解決の問題の数。 5) タイムリーな問題解決率と、未解決の問題の影響と範囲を分析します。 問題の処理をレビューし、未解決の問題の理由を分析し、改善のための提案を提出し、上記の内容を要約して問題レポートを作成します。
8.7 サービス保証
8.7.1 サービス可用性管理 サービスの可用性に対するリスクは、計画された間隔で評価および文書化する必要があります。組織はサービス可用性の要件と目標を決定する必要があります。合意された要件では、関連するビジネス要件、サービス要件、SLA、およびリスクを考慮する必要があります。 サービス可用性の要件と目標は文書化して維持する必要があります。 サービスの可用性を監視し、結果を記録し、目標と比較する必要があります。計画外の利用不能を調査し、必要な措置を講じる必要があります。 注: 6.1 で特定されたリスクは、サービスの可用性、サービスの継続性、および情報セキュリティに対するリスク入力を提供する可能性があります。
1. 可用性管理: 可用性管理レポート、可用性計画、可用性設計基準、ユーザビリティテストスケジュール。サービス可用性リスク評価を定期的に実施し、リスク対応策の基礎としてリスク評価レポートを作成します。 可用性は通常、一定期間内の稼働時間で表現されますが、「可用性 = 稼働時間/合意された期間」という相対値で表すこともできます。たとえば、1 年以内の可用性は 99.9% です。 ——サービス可用性のリスク評価を実行するには、サービスとサービス コンポーネントを監視、分析、評価する必要があります。 ——サービス可用性リスク評価は、サービスをサポートするサービス コンポーネント (つまり、資産または CI) から開始する必要があります。具体的な方法は、評価する必要があるサービスを選択し、ビジネス サービスの評価オブジェクトを直接選択し、それらをマッピングすることです。次に、その資産または CI によってサポートされるビジネス サービス、つまりビジネス サービス リスクによって反映される必要がある技術サービス リスクを明確にします。 ——アクセス パス内の各資産または CI の隠れた危険性と脅威を監視および特定することで、各資産または CI のサービス可用性リスクを特定し、評価することができます。資産または CI 間の直列および並列関係に従って、サービス全体の可用性を評価できます。リスクを評価される。 2. ネットワーク セキュリティ機器、ルーティングおよびスイッチング機器のインジケータ: ① 接続性、② 品質および遅延、③ アクセス制御。 通信リンク設備の指標: ① 接続性、② 品質と遅延。 コンピューティングおよびストレージ機器の指標: ① 接続性、② 品質および遅延、③ ビジネス コンピューティング。 特別なストレージ設計の指標: ① 接続性の向上、② 品質と遅延、③ ストレージの応答。 冗長性/展開アーキテクチャ (仮想化、ホット スタンバイ、クラスター、クラウド コンピューティングなど) の指標: ① 接続性、② 品質と遅延、③ スイッチング応答。 ——新規または変更されたサービス (8.5.2) の実装には、サービスまたはサービス コンポーネントの可用性目標指標、冗長化方法、検出および回復手段などを含む可用性設計標準の確立が必要です。 ——ユーザビリティ設計基準に従って、可用性または非可用性の指標、中断時間、障害の頻度と数などを含むテスト指標を確立し、テスト計画を策定し、テスト作業を実行する必要があります。 3. 可用性の監視、分析、および比較の要件は、サービスの対象となるコンポーネント (資産または CI) と関係 (8.2.6) に基づく必要があります。監視オブジェクトを選択し、監視および分析ツールを展開し、可用性インジケーターを設定する必要があります。すべての監視記録、隠れた危険性、および改善策を定期的に要約して整理し、以下を含むユーザビリティ分析レポートを作成する必要があります。 ——コンポーネントの可用性指標値(実際の値)と目標指標からの偏差; ——主要なビジネス機能可用性指標の値と目標指標からの偏差。 ——サービス可用性指標と目標指標からの逸脱。 ——計画的または計画外の利用不能。 ——SLAの満足度。 --改善のための提案。 計画外の利用不能に対して対象を絞った措置を講じます (通常は緊急対応が必要です)。計画外の利用不能の例は次のとおりです。 — 予期せぬ緊急のパフォーマンス問題による中断。 ——公共のイベント(大規模な停電など)または自然災害によって引き起こされる混乱。 ——可用性テクノロジーの急速な発展とそれに対応できないことによって引き起こされるビジネスの中断。 ——予想外の事業成長による混乱。
8.7.2 サービス継続性管理 サービス継続性に対するリスクは、計画された間隔で評価し、文書化する必要があります。組織はサービス継続要件を決定するものとします。合意された要件では、関連するビジネス要件、サービス要件、SLA、およびリスクを考慮する必要があります。 組織は、1 つ以上のサービス継続計画を作成、実装、および維持するものとします。サービス継続計画には、以下への参照を含める、または含める必要があります。 a) サービス継続を開始するための基準と責任。 b) 重大なサービス障害が発生した場合に実施される手順。 c) サービス継続計画を発動する際のサービス可用性目標。 d) サービス復旧の要件。 e) 通常の労働条件を回復するための手順。 通常のサービスエリアへのアクセスが失われた場合、サービス継続計画と連絡先リストへのアクセスを確保する必要があります。サービス継続計画は、計画された間隔でサービス継続要件に照らしてテストする必要があります。サービス環境に大きな変化が生じた後は、サービス継続計画を再テストする必要があります。テスト結果は記録する必要があります。レビューは各テストの後、およびサービス継続計画が呼び出された後に実行する必要があります。不備が見つかった場合、組織は必要な措置を講じるものとします。 組織は、サービス継続計画を開始するときに、原因、影響、および回復を報告する必要があります。
1. サービス継続リスク評価を定期的に実施し、リスク対応策の基礎となるリスク評価報告書を作成します。 2. サービス継続の目標は、サービス回復の優先順位を決定することです。これは、回復目標指標 RTO および RPO によって決まります。もちろん、サービス回復の優先順位と回復目標は、顧客のビジネス回復の優先順位と回復目標によって異なります。つまり、目標復旧時間 (RTO) は、災害発生後にサービスまたはビジネス機能が停止してから復旧するまでの時間要件を指します。目標復旧時点 (RPO) は、システムとデータが復旧する時点の要件を指します。災害発生後は復旧する必要があります。 RTO は、MSB: 財務上の損失、事業量の損失、業界の規制要件からの逸脱、評判の損失などの最大許容ビジネス損失値で構成されます。MAO: 最大許容ビジネス中断時間。 3. サービス継続計画のコンテンツ フレームワークの例は次のとおりです。 ——目的と範囲。 ——サービス継続目標。 - 開始の基準と手順。 ——対応プログラム。 ——組織構造と責任。 ——コミュニケーション方法と担当者リスト。 — 国家緊急対応センターなど、組織内外の依存関係や交流。 ——リソースの種類と量、取得と使用方法などを含むリソースの構築。 ——関連記録文書。 4. さまざまな理由により通常のサービスエリアに到達できない場合は、インシデント対応担当者がサービス継続計画と通信者リストを容易に入手できるように、適切なアクセスチャネルを確立する必要があります。 (インシデント処理に携わる担当者が通常のサービスエリアに到達できない理由は数多くあります。これには、火災などのインシデント現場の障害物、夜間に発生したインシデントや現場に到達できないなどの時間や交通の制約などが含まれます。シーンや場所の理由(海外出張など) 5. 定期的なサービス継続計画のテストを実施します。テスト要件には次のものが含まれます。 1) ビジネスまたはサービスに対応するサービス継続計画のテスト シーケンス。 2) 対応するサービス継続計画のビジネスまたはサービスのテスト頻度 (つまり、テストの頻度)。 3) イベントシナリオには、特定のイベントとイベントレベルを含める必要があります。 6. テスト計画を作成し、計画に従ってテストする必要があります。テスト計画の主な内容は次のとおりです。 1) テストの目標と、その目標を達成するための評価指標。 7) スケジュール、8) 訓練のリスクと対策、9) 試験記録。 7. テストおよび呼び出されたサービス継続計画のレビューには、以下が含まれます。 1) サービス継続計画は適切か。 2) 対応要員の技能が現場での処分に十分であるか。 3) 処分プロセス中の資源の取得と使用が実現可能であり、緊急対応作業のニーズを満たしているかどうか。 4) 緊急作業に費やした時間が RTO 要件を満たしているかどうか。 5) 緊急シナリオを設定する場合、非理想的な状況を考慮するだけでは十分ではありません。 6) 緊急時計画文書の品質が業務要件を満たしているか。
8.7.3 情報セキュリティ管理
8.7.3.1 情報セキュリティポリシー 組織に関連する情報セキュリティ ポリシーは、適切な権限を持つ経営陣によって承認される必要があります。情報セキュリティポリシーは文書化され、6.3c) のサービス要件と義務が考慮されるものとします。 情報セキュリティ ポリシーは、必要なときに利用できる必要があります。組織は、情報セキュリティ ポリシーを遵守することの重要性と、そのポリシーの SMS およびサービスへの適用可能性を以下に伝える必要があります。 a) 組織。 b) 顧客およびユーザー。 c) 外部サプライヤー、内部サプライヤー、その他の関係者。
組織は、適切な手段を通じて情報セキュリティ ポリシーを関係者に公開し、セキュリティ ポリシーに従うことの重要性と、SMS およびサービスへのセキュリティ ポリシーの適用可能性を明確にする必要があります。 組織は、組織および顧客サービスのコンポーネントと、サービスライフサイクルにおける関連担当者の責任に関連するデータに基づいて潜在的なリスクを特定し、リスクに基づいて適用可能な情報セキュリティポリシーを選択し、文書へのアクセスを通じて関連担当者に情報を提供する必要があります。研修等 情報セキュリティポリシーを周知します。適切な人々には、組織内の人々、外部プロバイダー、内部プロバイダー、その他の関係者が含まれます。
8.7.3.2 情報セキュリティ管理措置 SMS およびサービスに対する情報セキュリティのリスクは、計画された間隔で評価および記録する必要があります。情報セキュリティ ポリシーをサポートし、特定された情報セキュリティ リスクに対処するために、情報セキュリティ管理を特定、実装、運用する必要があります。情報セキュリティ管理に関する決定は文書化する必要があります。 組織は、外部組織に関連する情報セキュリティ リスクに対処するために、情報セキュリティ管理を承認および実施するものとします。 組織は、情報セキュリティ管理の有効性を監視および検討し、必要な措置を講じるものとします。
1. 環境の確立には、主にリスク評価の範囲、目的、評価基準の明確化が含まれます。リスクレベルのルール、資産、脆弱性、脅威のリスク割り当てルール、等 リスクの特定には、資産の特定、脅威の特定、脆弱性の特定が含まれます。 リスク分析には、資産、脅威、脆弱性間の関係の確立、リスクの可能性と影響の計算が含まれます (8.5.1.1 の変更影響分析方法を参照)。 リスク評価とは、リスク レベルのルールに従ってリスクをランク付けすることを指します。 リスク処理とは、リスク受容レベルとリスク選好に基づいて受容可能なリスクと受容できないリスクを判断し、コスト、利益、緊急性などを考慮して受容できないリスクに対する安全対策を選択し、処理の優先順位を設定することを指します。 2. リスク処理計画とは、取り扱うリスク、管理戦略、対応策、責任者、処理時間、残留リスクなどを含む安全対策を選択した後の作業計画です。 3. 安全管理措置を導入した後は、サービスの構成関係(8.2.6)に従って、サービスと情報資産(データを含む)との対応関係を事前に確立し、サービスの可用性と同様のアクセスパス(8.7. 1) アクセスパス上のすべての資産に対して以下の監視、評価、レビュー作業を実行する必要があります。 1. ネットワークセキュリティのエリア分割、セキュリティ機器の配備、境界セキュリティ対策の配備など、ネットワークセキュリティのアーキテクチャと設計が一貫している。 2. セキュリティ機能の設定は、セキュリティ ポリシーの要件と一致している必要があります。 3. 対処すべき資産の脆弱性が修復される。 4. 既知の脅威は封じ込められています。 5. 新たに特定された脆弱性またはパッチが適用されていない脆弱性については、侵入テスト手法を使用して、脅威による悪用の難易度が許容レベルを超えているかどうかを検証します。 6. サービスまたは顧客のビジネス システム全体が、ネットワーク セキュリティ レベルの保護要件など、国家または業界の規制要件を満たしていること。
8.7.3.3 情報セキュリティインシデント 情報セキュリティインシデントでは次のことが必要です。 a) 記録および機密扱いとされる。 b) 情報セキュリティリスクの考慮事項に基づく廃棄の優先順位。 c) 必要に応じてアップグレードします。 d) 解決する。 e) 閉じます。 組織は、情報セキュリティ インシデントを種類、量、SMS、サービス、関係者による影響ごとに分析する必要があります。情報セキュリティインシデントは報告され、改善の機会を特定するためにレビューされる必要があります。 注: ISO/IEC27000 シリーズは、関連要件を規定し、情報セキュリティマネジメントシステムの導入と運用をサポートするためのガイダンスを提供します。 ISO/IEC27013 は、ISO/IEC27001 と ISO/IEC20000-1 (この規格) の統合に関するガイダンスを提供します。
1. インシデントの抽出、記録、分析と委任、処理、アップグレード、解決と終了などを含む、情報セキュリティ インシデント処理プロセスを管理します。これらの内容は、インシデント管理 8.6.1 の関連内容を参照して実装できます。 2. 情報セキュリティリスクに基づいて情報セキュリティ戦略を決定し、リスクと戦略に基づいて情報セキュリティ管理策を選択、導入、運用し、情報セキュリティリスク処理計画を策定します。 3. 情報セキュリティインシデント報告書を定期的に作成し、関係者に提出します。情報セキュリティインシデントレポートの主な内容は次のとおりです。 1) インシデントの発見時期、資産、および影響。 2) インシデントの原因、つまり脆弱性と脅威の状況の分析。 3) イベントの処理プロセスと結果。 4) 出来事に起因する変化。 5) 発生頻度の低減、被害の軽減、再発防止のための改善策など、原因と改善策の概要。 6) 必要に応じて責任を負い、罰する。
9性能評価
9.1 監視、測定、分析および評価 組織は次のことを決定する必要があります。 a) SMS およびサービスの内容を監視および測定する必要がある。 b) 有効な結果を保証するための、適用可能なモニタリング、測定、分析および評価方法。 c) 監視および測定を実施する。 d) 監視および測定の結果は分析および評価されるべきである。 組織は、結果の証拠として適切な文書化された情報を保持するものとします。 組織は、サービス管理目標に照らして SMS のパフォーマンスと有効性を評価する必要があります。組織は、サービス要件に対するサービスの有効性を評価するものとします。
サービスプロバイダーは、サービス管理システム (SMS) とサービスを監視および測定するための適切な方法を採用する必要があります。これらの方法には、内部監査と管理レビューが含まれる必要があります。内部監査と管理レビューの目的は文書化する必要があります。内部監査と管理レビューでは、サービス管理システム (SMS) とサービスがサービス管理目標を達成し、サービスのニーズを満たす能力があることを確認する必要があります。 ISO/IEC 20000-1 の要件、サービス管理システム要件、またはサービスプロバイダーが特定したサービス要件への非準拠を特定するものとします。 内部監査と管理レビューの結果は、不適合、関連事項、特定された措置を含めて記録される必要があります。結果とアクションは関係者に伝達される必要があります。 モニタリングと測定の内容には、少なくとも次のものが含まれます。
9.2 内部監査/レビュー
9.2.1 組織は、SMS に関する情報を提供するために、計画された間隔で内部監査を実施するものとします。 a) 以下に準拠します。 1) SMS に対する組織独自の要件。 2) この規格の要件。 b) 効果的な実装と保守。
9.2.2 組織は次のことを行うものとします。 a) 頻度、方法、責任、プログラム要件、報告を含む監査プログラムを計画、確立、実施、維持します。これには以下が考慮されます。 1) 関連するプロセスの重要性。 2) 組織に影響を及ぼす変更。 3) 前回の監査の結果。 b) 監査基準と各監査の範囲を決定する。 c) 監査プロセスの客観性と公平性を確保するために監査人を選定し、監査を実施する。 d) 監査結果が関連する経営陣に確実に報告されるようにする。 e) 監査計画の実施と監査結果の証拠として文書化された情報を保管します。 注: 1SO19011 は、管理システムの監査に関するガイダンスを提供します。
文書化された手順を作成して、監査の計画、実施、結果の報告、記録の維持に対する責任と権限を定義する必要があります。 監査プログラムを計画する必要があり、監査対象のプロセスと領域の状況と重要性を考慮し、監査の基準、範囲、頻度、方法を文書化する必要があります。 監査人の選定と監査の実施は、監査プロセスの客観性と公平性を確保する必要があります。監査人は自分自身の作業を監査すべきではありません。不適合は通知され、優先順位が付けられ、行動の責任が割り当てられる必要があります。監査対象領域を担当する管理者は、発見された不適合とその原因を排除するために、必要な是正および是正措置が速やかに講じられることを保証するものとします。アクティビティの追跡には、実行されたアクションの検証と検証結果の報告が含まれる必要があります。
9.3 マネジメントレビュー
経営トップは、計画された間隔で組織の SM とサービスを見直し、継続的な適合性、適切性、有効性を確保する必要があります。 管理レビューには以下を含める必要があります。 a) 過去のマネジメントレビューで決定された施策の実施状況。 b) SMS に関連する社外および社内の事項の変更。 c) SMS のパフォーマンスと有効性に関する情報。以下の要素とその傾向が含まれます。 1) 不適合および是正措置。 2) 監視および測定結果。 3) 監査結果。 d) 継続的な改善の機会。 e) 顧客およびその他の関係者からのフィードバック。 f) サービス管理ポリシーおよびこの標準で要求されるその他のポリシーを遵守し、適用します。 g) サービス管理目標の達成。 h) サービスのパフォーマンス。 i) サービスの提供に関与する他の当事者のパフォーマンス。 j) 現在および予測される人的、技術的、情報的、財政的リソースのレベル、および人的および技術的リソースの能力。 k) リスク評価結果の有効性と、リスクと機会に対処するために講じられた措置。 l)SMSおよびサービスに影響を与える可能性のある変更。 マネジメントレビューの成果には、継続的な改善の機会と、SMS およびサービス変更の要件に関連する決定が含まれる必要があります。
9.4 サービスレポート
組織は報告要件とその目的を決定する必要があります。 SMS のアクティビティとサービスの提供に関する情報は、SMS とサービスのパフォーマンスと有効性に関するレポートを作成するために使用する必要があります。サービスレポートには傾向を含める必要があります。 組織はサービスレポートの結果に基づいて意思決定を行い、行動を起こす必要があります。合意された行動については、関係者全員に通知される必要があります。 注: 必要な報告は、この規格の関連条項で指定されています。追加のレポートも生成できます。
1. サービスプロバイダーと関係者は、識別、目的、読者層、頻度、データソースの詳細を含む各サービスレポートの説明を交渉し、記録する必要があります。 サービス レポートは、サービス提供およびサービス管理プロセスを含むサービス管理システム (SMS) アクティビティからの情報を使用して生成する必要があります。サービスレポートには少なくとも以下が含まれます。 ——サービスレベル目標に対応したパフォーマンス。 ——少なくとも主要なイベント、新しいサービスまたは変更されたサービスの導入、開始されたサービス継続計画を含む、関連する主要なイベント情報。 ——作業負荷や定期的な変更を含む作業負荷の特性。 —— ISO/IEC20000-1 のこの部分の要件、サービス管理システム (SMS) 要件またはサービス要件、および識別の理由に基づいて検出された失格。 ——トレンド情報; ——顧客満足度測定、サービス苦情および満足度測定と苦情の分析。 サービスプロバイダーは、サービスレポートの結果に基づいて決定を行い、措置を講じる必要があります。連携した措置を関係者に伝達する必要があります。 2. サービス レポートは、サービス プロバイダーがサービス品質データを収集および監視するためのツールであり、通常、顧客とのサービス契約で合意されたレベルでの SLA 達成に関する月次または四半期レポートを指します。 3. サービスレポートの内容の例: 1) 報告の目的: ——管理者、IT サービス プロバイダー、およびビジネス部門がサービスの提供状況を理解するのに役立つ、サービス レベル契約と比較した現在のサービス ステータスの客観的な反映。 ——意思決定の情報基盤および効果的なコミュニケーション手段として、タイムリーで信頼性が高く、簡潔かつ十分に正確なレポートを作成します。サービス ステートメントは、レポートの受信者がレポートの内容を理解するのに役立つものでなければなりません。 ——サービス管理者が意思決定を行うための証拠を提供し、サービス提供プロセスが確実に管理されていることを確認します。 ——サービス管理の改善と変更活動のための意思決定、計画、実行の参考資料を提供します。これは、サービスとリソース利用の継続的な改善に役立ちます。 2) 対象読者:企業経営者、顧客、その他関係者等 3. レポートの概要: レポートのトピック、サービスプロバイダーの紹介、サービスレポートのサイクル、サービスレポートの提出時間 4. このサイクルのサービスの全体的な概要: サービス品質、重大な障害の発表、重大な変更の発表 5. サービスパフォーマンス。傾向などを含め、サービスパフォーマンスとサービスレベル契約の比較を記録します。 6. 主要な出来事/問題のレビュー。 7. 主要な変更点のレビュー。 8. ITサービスのトレンド分析。 9. 顧客満足度の分析。 10. 報告されたデータソース。