目標: サービスの収益を最大化し、リスクを最小限に抑えます。 測定: サービスのリスクと利点に関する測定方法を確立します (9.1 SMS およびサービスのモニタリング、測定、分析、評価と併せて)。 選択: サービスの選択と優先順位の方法。つまり、市場と顧客に向き合い、どのサービスを選択するか、およびサービスの優先順位をどのように設定するか。サービス計画 8.2.2 に対応します。 資産配分: サービスをサポートするためにどの資産が使用されるか、資産間の関係は何かなどを明確にします。資産投資はサービスコストの構成要素であり、資産管理 8.2.5 および配分管理に対応して、収益を最大化し、リスクを最小化するように最適化する必要があります。 8.2.6 ; 進化: 提案、開発、運用、オフラインに至るサービスの完全なプロセス。運用中のサービスは通常、サービス カタログ、特にサービス計画 8.2.2 に対応する特定の顧客との契約によって決定される「サービス カタログ」によって表されます。 、サービス ディレクトリ管理 8.2.4: 管理と制御: 8.2.3 に対応し、コストを管理し、リスクを軽減するために、ライフサイクル内の関係者を管理および制御します。 根拠: 財務管理はサービス ポートフォリオ管理への重要な入力であり、サービス提供に採用されているコスト構造を理解することで、企業はコストのベースラインを決定できる可能性があります。正確なコスト計算には、8.4.1 に対応する財務情報、サービス需要情報、組織のサービス能力情報などを理解する必要があります。

1. 組織計画サービスの基礎として（サービスポートフォリオ管理の一環として）、さまざまな進捗状況におけるサービスとその要件（法律、規制、契約、および関係者のその他の要件を含む）を定期的に決定および記録します。組織が計画するサービスは、特定の顧客を対象としない市場志向のサービスである場合もあれば、特定の顧客を対象としたサービスである場合もあります。 2. 既存のサービスは、サービス カタログを通じて提供されます。新しいサービスは、運用可能で提供可能なサービスになるために、提案、開発、およびその他のプロセスを経る必要があります。サービスの変更は、既存または確立された SMS の変更管理を通じて管理されます。 3. サービスの重要性の決定は、組織の利益とコスト、サービスによってサポートされるビジネスの重要性と利点、および時間の緊急性 (可用性など) に関連します。他の関連当事者のコンプライアンス、サプライヤーの利益とコストなどの監督。サービスの重要性は、特定の顧客に合わせて調整することも、組織自体を中心に構築することもできます。重要度にかかわらず、分析・評価には評価モデルを確立する必要があります。 4. 優先順位を設定する際には、次の要素を考慮する必要があります。変更リクエストと新しいサービス、またはサービス管理目標を生成するビジネス ニーズ、変更リクエストとサービス提案を実装する際の投資、メリット、およびリスク。

1. 評価基準: サービスに対する他の関係者の影響を考慮する必要があります。影響の決定的な要素には、サービスのライフサイクルにおける他の関係者の責任、参加の頻度、組織が支払うコスト/費用、およびその役割が含まれます。サービスの利点とリスクについては、これらの要素に基づいて評価モデルを構築する必要があります。 2. 選択基準: 他の当事者を選択する優先順位は、その影響の大きさに基づいて決定される必要があります。 組織が決定し記録すべきことは、他の当事者とその責任の特定に基づいて、他の当事者に対する 3 つの成果物 (つまり、サービス、サービスコンポーネント、サービスプロセス) のリストを作成し、それらを組織と比較することです。責任は統合されています。顧客のニーズを満たし、サービス管理目標を達成するため。目標は、サービスの効率を向上させ、コストとリスクを削減することであり、構成管理を通じて統合された方法と結果を達成する必要があります。

1. サービスおよびサービス要素の有効性の測定および評価は、以下の点に焦点を当てる必要があります。 ニーズを満たすサービスの有効性指標には、顧客のビジネス価値の満足度が含まれます。これらの指標におけるサービスの役割は、次の点に基づいて決定される必要があります。サービスの可用性、情報セキュリティ、サービスの継続性などの観点からの有効性指標に変換します。サービスの可用性は、キャパシティ、サービス コンポーネントの有効性指標 (可用性など) と密接に関連しています。測定の基礎は、サービス有効性指標とサービスコンポーネント有効性指標の対応関係を確立することです。対応関係は、サービスが完了するコンポーネントのパスを使用して確立できます。 2. 顧客のビジネス、サービス、サービスコンポーネントの関係を構成管理システムを通じて実現し、それに応じた測定および評価モデルを確立できます。

1. サービス カタログのサービスには、ビジネス サービスとテクニカル サービスが含まれます。ビジネス サービスは、顧客のビジネス システムに直接必要なコンピューティング機能で構成されます。一方、テクニカル サービスは、組織が顧客のビジネス システムに提供する技術的なアクティビティで構成されます。 2. 一般的な技術サービスは、サーバー、ネットワーク機器、コンピューター室の空調装置などの情報資産の種類を第一の次元とし、その後、サーバーの設置および導入サービスなどの技術サービスを形成するために技術的な活動の次元を追加します。 、サーバー検査サービスなどのテクノロジー アクティビティは次のとおりです。インストールと展開には、初期インストールと展開、アップグレードとパッチ適用、変換、構成とテスト、資産の特定と監視、日常の検査と検査、トラブルシューティング、移行、バックアップ、およびリカバリ、監査と評価、放棄（アンインストール、切断、クリア、保存、破棄）など。 3. サービスの移転、サービスのオフライン、新しいサービスなどが発生した場合、組織はサービス カタログを適時に更新し、維持する必要があります。

1. 資産とは、サービスの提供に使用される資産を指します。これには、サービスの提供に不可欠な資産である限り、組織、顧客、サプライヤー、その他の当事者の資産が含まれる場合があります。 2. 情報資産の分類: コンピュータハードウェア、通信設備、物理的サポート設備などの物理的資産、文書やデータベースなどのソフトウェア、アプリケーションソフトウェア、システムソフトウェア、開発ツールやプログラムなど。製品を生産するか、意欲や評判などの無形資産を提供する能力。 3. 資産はライフサイクル全体にわたって管理される必要があります。組織は、他の当事者の資産についてのみ完全なライフサイクル管理を行うことができ、責任と管理作業は他の当事者に帰属します。 4. 組織は資産台帳を作成し、定期的に維持する必要があります。資産台帳の属性には通常、資産の大カテゴリ、中カテゴリ、小カテゴリ、名前、コード、ステータス、責任者、場所、サプライヤーなどが含まれます。たとえば、情報セキュリティ 8.7.3 では、組織は実際の状況に応じて属性を追加する必要があります。 、アセットには安全な割り当て属性を追加する必要があります。

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 です。

1. 顧客関係管理の核心は価値です。これは、Win-Win の状況を達成するための、顧客の特定、維持、発展のライフサイクル プロセスにおける顧客価値の特定、維持、発展の長期的かつ継続的な動的な管理を意味します。価値判断には、組織が顧客に提供する価値、組織の価値に対する顧客の貢献が含まれます。 顧客関係管理には、顧客情報の収集と顧客データベースの確立、顧客の分類と主要なアカウント管理の実行、顧客の苦情への適切な対応、忠実な顧客の育成の 3 つの段階が含まれます。 2. ビジネス環境とは、政策、経済、技術、社会文化、顧客、競合他社などの外部環境要因のほか、組織ビジョン、戦略目標、内部組織構造、人事責任、製品などの顧客のビジネス環境を指します。 /サービス、生産ラインの運用、供給 チェーン管理、顧客関係管理、アプリケーション システム、IT インフラストラクチャなどの内部環境要因。 3. サービスパフォーマンス指標を確立するための基礎は、サービスレベル契約のサービス管理目標 6.2、サービス提供 8.2.1、および目標指標 8.3.3 です。 4. サービスに関する苦情は満足度評価の一部です。苦情の提出、受付と記録、処理、確認、終了、報告およびその他の活動を含む、サービスに関する苦情のプロセス全体を管理する専任の担当者が必要です。苦情チャネルは組織のコミュニケーションチャネルの一部である必要があり、通常のチャネルで苦情を解決できない場合は、組織は管理ホットラインなどのエスカレーション方式で苦情を解決するための他のチャネルを提供する必要があります。等

1. サービスおよび SLA の監視要件は次のとおりです。監視する必要があるサービス項目は、SLA およびサービス カタログに基づいて明確に定義される必要があります。各サービス項目の実装プロセスと主要なアクティビティ（サービスによってサポートされる顧客のビジネス活動）。サービス）を明確にする必要があります。 インシデント作業ログなどのサービス記録、週次レポート、月次顧客満足度レポートなど、実装作業の記録情報を取得する必要があります。 主要なアクティビティについては、次のような情報システム ステータス情報を取得する必要があります。これには、平均値、ピーク値とトラフ値、定期的な物理ステータスを含む、可用性、パフォーマンス、およびセキュリティのシステム構成パラメータが含まれます。 2. 評価指標の目標値: サービス/システムの可用性指標、サービス/システムの容量指標、RTO、RPO など。各タスクの完了率、正解率、適時率など 組織は、収集したモニタリング情報に基づいて評価指標の実際の値を推定し、目標指標と比較し、SLA レビューを実施する必要があります。 レビューのポイントは次のとおりです。サービスモニタリングの結果に基づいてサービスレベルを項目ごとに評価し、SLA を満たしているかどうかを判断し、SLA の評価に基づいて SLA の維持または変更の要件を決定します。結論。 3. レビュー結果を要約してサービス レベル レポートを作成する必要があります。レポートの主な内容は次のとおりです。サービス SA 満足度、顧客満足度。 SLA を満たしていない企業については、サービス カタログとサービス レベルの最適化、ポジションと人材を含むサービス能力の最適化、スキルとサービス プロセスの最適化、サービス プロセスの最適化などの改善措置を提案します。 ; サービス リソースの最適化。その他の改善。

1. サプライヤーのパフォーマンスは、提供された結果に基づいてパフォーマンス指標を確立し、定期的な再評価、継続的な選択または撤退の基礎として毎日の追跡、監視、評価を実施する必要があります。これは、顧客と署名された SLA (つまり、サービスパフォーマンス指標全体) に基づいており、サプライヤーの責任と成果物を考慮し、構成管理 8.2.6 で確立されたサービス、サービスコンポーネント、CI などの間の依存関係を組み合わせて、サプライヤーの責任と成果物を明確にし、サービス全体における関係者と成果物が決定され、パフォーマンス指標が最終的に決定されます。 2. 外部サプライヤーのリスクの特定は、パフォーマンスの逸脱（顧客 SLA からの逸脱）に基づいて行う必要があります。これには、具体的には次のようなものがあります。外部サプライヤーによって提供される結果。変更によって引き起こされる可能性のあるリスク。これは最終的には直接的な業績逸脱のリスクに反映されます。外部サプライヤーの経営状況、倒産、コンプライアンスなど、外部サプライヤーによって管理されるリスク。 3. 外部サプライヤーとのインターフェースには、担当者間の通信インターフェース、双方の管理システム間のインターフェース (顧客関係管理システム、プロジェクト管理ツールなど)、および運用保守管理ツール (企業が使用する管理ツールなど) が含まれます。双方のインターフェースなど） 4. 両当事者間の紛争、契約変更、その他の問題を解決するために、契約に対する外部サプライヤーの満足度を定期的に確認します。契約のレビューは専門の部門や担当者によって組織され、定期的に実行されるべきであり、契約要件から大きく逸脱する外部サプライヤーに対しては、双方が契約を維持すべきか変更すべきかを明確にする必要があります。 SMS およびサービスに対する契約変更の影響を評価するには、8.5.1.1 の影響ベンチマークを参照する必要があります。たとえば、撤退を希望する外部サプライヤーに対しては、適切な対策を講じる必要があります。サービスの再設計と変換を事前に行う必要があります (8.5)。当事者間の紛争については、契約の規定を履行し、問題を直接解決して解決する必要があります。

組織は、サービス レベル目標、その他の約束、活動、インターフェイスを含む契約を内部サプライヤーまたは顧客と締結する必要があります。内部サプライヤーまたはサプライヤーとしての顧客の管理プロセスは、8.3.4.1 の外部サプライヤー管理プロセスを参照できます。 サービスレベル目標およびパフォーマンス指標の確立は、外部サプライヤーのサービスレベル目標、パフォーマンス指標、およびその他の関連コンテンツを参照することができます (8.3.4.1)。 契約の内容構成は、外部サプライヤー契約の関連内容を参照する場合があります (8.3.4.1)。インターフェースの定義と管理は、外部プロバイダーインターフェース（8.3.4.1）に関する内容を参照できます。 組織は、内部サプライヤーまたは顧客のパフォーマンスを定期的に監視および評価して、サービス レベル目標またはその他の合意された約束が満たされているかどうかを判断し、外部サプライヤーに改善を要求する必要があります。

組織は、サービスのコスト対象とコスト分類を明確にする必要があります。コスト対象には、サービスをサポートする組織のツールと資産 (ソフトウェアとハ​​ードウェア)、人員、IT インフラストラクチャ、場所などが含まれます。コスト分類には、直接コストと間接コストが含まれます。コスト オブジェクトがコスト見積もりに含まれるかどうかは、そのオブジェクトが組織に属するかどうかに関係なく、両当事者によって共有され、共同で構築される部分が割り当て可能なコストとなります。 組織は実際のコストを定期的に監視、評価、報告し、予算の有効性を確認する必要があります。

1. サービス要件を管理して、組織がサービス要件をタイムリーに取得し、サービス収益を増やすために可能な限り SLA 署名可能なサービスに変換できるようにします。 2. サービス ニーズは顧客のビジネスの変化から生じ、需要の獲得がサービス ライフ サイクル プロセスの開始点となります。需要管理の鍵は、特定の顧客に対する需要分析モデルを確立することです。モデルには主に次の内容が含まれます。 入力: 以下のような顧客のビジネス、顧客の IT システムおよびサービスを含みます。 —顧客のビジネス: 顧客のコアビジネスとサポートビジネスを区別し、コアビジネスの現状と発展傾向、特にビジネスキャパシティの変化傾向に焦点を当てる必要があります。 、ビジネスキャパシティのピーク期間と特別な日（ダブルイレブンやインターネットビジネスのその他の日など）。 1. お客様のITシステム：アップグレード、スクラップ、リソース容量（有効利用率など）、新技術の採用、新システムの立ち上げ、アプリケーションのクラウドコンピューティングへの移行など。 1 対 1 のサービス: 実行中のサービス (顧客サービス カタログ内のサービス) のステータス (サービスの有効な使用または消費、SLA によるサービスの満足度、サービス価格の顧客の評価を含む)、サービスの変更リクエスト、サービス プロバイダーの顧客の評価と変更、など。 アウトプット: 以下のような顧客のビジネス、顧客の IT システムおよびサービスが含まれます。 1. 顧客のビジネス: 新しいビジネス能力 (ピーク時および特別日のビジネス能力を含む) およびコンピューティング能力またはビジネス サービスの需要。 お客様のITシステム：機能、パフォーマンス、容量などの新規追加および変更、および対応する技術サービス要件。 One to One サービス: 撤退した顧客サービスプロバイダー、顧客の中核事業運営パフォーマンス、顧客 SLA 満足度、サービスコストパフォーマンスに関する顧客評価、および新規サービス要件と変更されたサービス要件。 新しいサービス要件または変更されたサービス要件は、8.2.2 を通じて特定および文書化できます。 3. 需要管理はキャパシティ管理と密接に関係しており、顧客システムのリソースキャパシティの変化により、ビジネス サービス (コンピューティング能力) および技術サービス (検査、障害処理など) の需要が発生する可能性があります。ここでのリソース容量は、容量管理にも適用されます。 需要管理は財務管理に関連する必要があり、組織管理が財務に対する需要の影響を予測および管理できるように、需要を財務データで定量化する必要があります。 組織は、顧客の既存のテスト ツールを展開または採用し、需要分析モデルの入力データを取得し、定期的に需要分析を実施し、顧客の既存のサービス消費量と新しいサービス ニーズに焦点を当てた需要分析レポートを作成する必要があります。 4. 必要に応じて、組織は SMS のパフォーマンス指標として需要換算率 (正式な SI、A に換算) を使用できます。

1. 容量要件のソースを明確にし、リソース容量要件を決定、記録、維持します。キャパシティ要件のソースはサービス要件とパフォーマンス要件であり、リソースには人的、技術的、情報、財務の 4 種類のリソースが含まれます。 2. 顧客のビジネス運営を検討するとき、組織は、ビジネス能力、サービス能力、リソース能力という 3 つのレベルの能力に注意を払う必要があります。組織のコストは、最終的には人的資源、技術、情報、リソースの 4 つのリソースの消費に反映されます。財源。 3. キャパシティ プランニングには、キャパシティの予測、予測されたキャパシティの予想される影響、キャパシティ変更の時間スケールとしきい値が含まれます。 4. 時間スケールとは、特定の物理プロセスを完了するのにかかる時間の平均測定値を指します。一般に、物理プロセスの進化が遅いほど、その時間スケールは長くなります。物理プロセスに関与する空間範囲が広くなるほど、その時間スケールは長くなります。サービス容量の変化の時間は、サービス容量の変化が安定しており、時間スケールが長い場合、リソース容量の変化は小さく、予測モデルは単純であるとみなすことができます。逆に、予測モデルは複雑であり、予測精度は比較的低いです。つまり、時間スケールが小さいということは、サービス容量が大きく変化することを意味する。サービス容量の変更のタイミングを決定する要因には、次のものが含まれます。 1) ピークと谷の交互周波数や曲率など、顧客のビジネス能力ラインの振動の程度。 2) 顧客のビジネスキャパシティのピーク値、トラフ値、通常値、およびそれらに対応する時間帯 (たとえば、午前 9 時から 11 時までがピーク時間帯)。 3) サービスコンポーネントの負荷分散。 5. キャパシティ計画に従ってサービスの展開が完了した後、キャパシティがサービスのキャパシティとパフォーマンスの要件を満たしているかどうかを確認するために、監視と分析の措置を講じる必要があります。逸脱がある場合は、改善策を提案する必要があります。 容量監視のコンテンツには、次のようなコンピューティング リソース、伝送リソース、ストレージ リソースが含まれます。 1. コンピューティング リソース: メモリ、CPU などの有効利用率やタイムリーな応答率などのパフォーマンス指標。 2. 送信リソース: 帯域幅の有効利用率と、QoS や遅延などのパフォーマンス指標。 3. ストレージ リソース: ストレージ スペースの有効利用やタイムリーな応答率などのパフォーマンス指標。 監視データを分析してアラーム（容量不足によるパフォーマンス障害など）を生成するには、アラームの基準となる容量のしきい値を設定する必要があります。

1. 組織は変更管理ポリシーを明確にし、正式な文書を策定する必要があります。変更管理ポリシーには、変更管理の範囲に含まれる資産 (または CI) およびその他の要素 (SLA など)、変更の種類と破棄プロセス、および変更の影響の評価基準が含まれます。 変更管理制御の対象となるサービス コンポーネントには、以下で説明するように、サービスをサポートするすべての資産およびその他の要素が含まれている必要があります。 ——お客様の業務運営を支える資産：主に情報システム、計算機室等の物理設備を指します。 ——顧客の業務運営をサポートする組織の資産: 組織が技術サービスのみを提供する場合、組織が顧客の業務運営をサポートする資産も提供する場合 (前の項目を参照)、これらの資産はサービス監視および管理ツールを指します。変更管理制御の対象となる。 ——サプライヤーの資産: サプライヤーが提供するサービス、サービス コンポーネント、機能に応じて、サービスの監視および管理ツールを提供したり、サービス コンポーネントを組織に提供したり、組織がそれらを展開して顧客の業務運営をサポートしたりする場合があります。情報システムでは、これらの資産は変更管理制御の対象となる必要があります。 ——変更の種類: 変更は通常、情報資産の種類と、インストールと展開、アップグレード、パッチ、変換、移行、廃棄などの技術的アクティビティの 2 つの側面に基づいて分類されます。 2. 変更レベルは、通常、変更の影響度に基づく、より厳格な変更の分類です。変更のレベルを評価するための基本的な要素は、キャッチアップ (時間が基準) と影響度の分析です。影響の程度は、次の要素を総合的に考慮する必要があります。 ——システムまたはサービスのイベント: 効率の低下、中断、リークなど。 ——国や社会が関与するシステムやサービスは、個人の安全と目に見えない影響に焦点を当て、漏洩を優先する必要があります。 ——リアルタイム性の高いシステムやサービスは、主に財務、顧客、生産能力、評判、ブランドなどへの影響に焦点を当て、中断イベントを優先する必要があります。 ——社内でのみ使用されるシステムまたはサービスの場合、効率低下イベント、主に生産能力への影響を優先する必要があります。 ——顧客が使用するシステムやサービスは、顧客や生産能力などへの影響を考慮し、中断イベントを優先する必要があります。 3. 変更評価ルールに従って変更レベルを設定します。変更評価ルールには少なくとも以下が含まれます。 標準的な変更: 成熟した運用、高い再現性、最小限の影響による変更。 一般的な変更: システムに一定の影響を及ぼし、レビューに IT マネージャーとビジネス マネージャーの参加が必要な変更。 重要な変更: 最高幹部によるレビューが必要な変更。 緊急の変更: 変更時間の要件は緊急であり、変更の成功率と完了の適時性に重点が置かれます。 4. 変更の実行プロセスを追跡するには、新規、レビュー済み、計画中、レビュー中、レビュー済み、スケジュール済み、実装済み、待機中、変更済み、完了、終了などの変更ステータスが明確である必要があります。

1. サービスのリクエストを追加すると新しいサービスが生成される場合があり、サービスの削除または転送はカスタマー サービス カタログと SLA に大きな影響を与えるため、カスタマー サービス カタログと SLA の変更が必要になる場合があります。このような場合、サービスの再設計と変更が必要になることがあります。変換された。 2. サービスの追加、削除、または転送のソースは Service Demand Management 8.4.2 であり、特定の条件を満たし、組織の責任または契約の範囲内にあるサービス変更リクエストを形成し、サービス設計と署名が必要です。最後に、顧客のビジネス システムに展開および実装する必要があります。 3. 資産または CI およびその他の要因の変化には、以下が含まれます。 a. 顧客の業務運営の変更に伴うサービスの変更には、サービスの設計と変換が必要です。 b. 顧客の IT インフラストラクチャの変更によりサービスが変更され、サービスの設計と変換が必要になります。 c. 顧客のビジネス環境の変化 (4.1、8.3.2 を参照) は、顧客の業務運営の変化と顧客の IT インフラストラクチャの変化につながり、サービスの設計と変換が必要になります。

1. 変更リクエストは承認され、優先順位が付けられる必要があります。承認と優先順位の決定要因には、リスク、ビジネス上の利益、実現可能性、財務上の影響が含まれます。 2. 変更要求は、変更の開始者の基本情報、変更の対象と範囲、変更の提案時期、変更の内容、変更の理由、変更のリスク、変更の種類を含む標準化された文書 (RFC フォームなど) に形成される必要があります。 、変更レベル、変更ステータス、変更計画、変更障害対応計画（ロールバック、リカバリ、緊急時などの計画）、コスト予算など、その他の必要な要素。 3. 変更承認組織には以下が含まれる場合があります: 変更管理者: 変更要求の事前審査を実施、変更マネージャー: 一般的な変更を承認、変更管理委員会: 緊急または重大な変更を承認。上記の組織は通常、サービスプロバイダー、顧客、サプライヤー、その他の必要な組織を必要とします。人員構成。 変更（特に大きな変更）を承認するために必要な入力内容には、変更要求フォーム、事前レビューと受諾意見、変更実施計画、変更障害対応計画（ロールバック計画、緊急是正措置など）、人的組織構造、責任の紹介、技術的な実現可能性の説明、解決すべき問題または利点の説明、コスト予算の説明、リスクの説明、ビジネスへの影響および廃棄措置。 4. 変更テストの要件は次のとおりです。 ビルドされた変更、実装計画、フォールバック計画、バックアップ計画、緊急時対応計画をテストする必要があります。 変更テスト計画は、テストの内容、担当者、タイムスケジュールなどに基づいて作成する必要があります。主な内容には、単体テスト、結合テスト、回帰テストなどのテストの種類、テストケースの設計、およびテストの内容が含まれます。テスト環境の構築、テスト記録テンプレート、テスト担当者の組織および責任。 特別なテスト環境 (準本番環境など) を構築する必要があり、本番環境での変更テストは禁止されています。 テスト実行プロセス中に次の作業を実行する必要があります: テストの問題の発見と追跡、テストの結果。 5. 検証後に承認された変更については、実施計画を策定し、顧客、サプライヤー、その他の関係者に通知する必要があります。実装計画の主な内容には、実装の内容と範囲、構築された変更とロールバックまたは修復計画、実装のタスクと担当者の配置、およびその他の計画が含まれます。必要な要素。 6. 変更に関連する記録と報告書を定期的に収集して整理し、変更の実施に関する統計を作成し、開発傾向を特定する必要があります。主な内容は次のとおりです。 ——数量: 変更リクエストの合計、フィルターされた変更リクエスト、承認された変更リクエスト、成功/失敗した変更、緊急変更、およびさまざまなタイプ/レベルの変更の数 (標準的な変更の数を含む)。 ——時間: リクエストからクローズまでの平均処理時間と各リンクの平均時間 (平均承認時間など)。 ——配分: 資産/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更新を完了します。

1. 組織は、サービス計画の結果が実現可能かつ実装可能であることを保証するために、サービス計画に基づいてサービス設計作業を実行する必要があります。 サービス計画は、構築タスクのフレームワーク要件を設定することに重点を置いています。これは、管理のための青写真形式の計画です。一方、サービス設計は、実装するサービスの重要性と規模に基づいて明確にする必要があります。予備設計、詳細設計、物理的な配置を伴う施工図の設計（コンピュータ室設備の建設など）。 2. d)項では、新規または変更されたSLA、契約、およびその他の文書化された合意要件を満たすための設計計画のレビューを要求しており、これはより具体的な受け入れ基準です。 条項 e) は、SMS に関するポリシー、計画、プロセス、手順、措置、知識の新規または変更の確立を伴う SMS 変更のリスクを強調しており、適切な対応策が講じられるべきであるとしています。 サービスを設計したら、構築して移行する前にカスタマー サービス カタログを更新する必要があります。

1. 組織は、新規または変更されたサービスを構築し、関連する標準 (サービス要件 (SA など)、設計ソリューション、およびサービス受け入れ基準を含む) が満たされているかどうかを確認するためのテスト作業を完了する必要があります。 2. サービス構築の結果は以下の種類で表示されます。 a) お客様の業務運営をサポートするソフトウェアパッケージ。 b) 顧客の業務運営をサポートする統合された設備と施設。 c) 最初の 2 つの項目を含むソフトウェアとハ​​ードウェアの統合の組み合わせ。 ——IaaS、PaaS、SaaSなどのクラウドサービス。 ——データストレージやデータ分析など、お客様の業務運営を支援するデータサービス。 ——顧客のビジネス システムのインストール、展開、アップグレード、強化/パッチ適用、セキュリティ インシデントまたは障害の処理、構成操作、検査と検査、評価と評価、監査などの技術活動/技術サービス。 ——その他、映像・音声サービス等 3. 構築されたサービスには、次のように、サービス結果のタイプと一致するビジネス環境要因も含める必要があります。 ——物理的環境: コンピュータ室の空調、電気、キャビネット、統合配線およびその他の機器および設備、空間レイアウト、物理的接続などを含みます。 ——ネットワーク環境: ネットワーク アーキテクチャとコア機器、ネットワークの物理トポロジと論理トポロジ (ネットワーク プロトコルやポートなど)。 ——コンピューティング環境: 物理サーバーまたは仮想サーバー、ストレージなどの構成と接続。 ——セキュリティ環境：ネットワーク境界、セキュリティ機器などの設定と接続。 ——管理環境: 人材と組織の要件、技術活動、サービスプロセスなどの関係。 つまり、ソフトウェアパッケージを提供するだけでは顧客が求める「サービス」ではなく、ソフトウェアパッケージの動作環境も考慮してサービス設計を行う必要があります。 4. テストは、導入前のテストです。テスト環境は、本番環境とできるだけ似たものを構築する必要があります。たとえば、多くの金融機関では、「準本番環境」を構築しています。これは実稼働環境と似ています。テスト環境を構築する場合は、前述のビジネス環境要因を考慮して、サービス要件 (SLA など)、設計計画、サービス受け入れ基準などを考慮する必要があります。 5. 結果をリリースおよび展開した後、組織は、期待される結果（計画における目標と青写真、設計計画における結果、サービス構築における結果タイプなど）と実際のサービスの展開および運用との対応関係を確立し、決定を提供する必要があります。適合度を確認し、顧客、サプライヤー、規制当局などに提出します。

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) 失敗または成功したリリースをレビューし、成功または失敗の理由を分析、判断、確認し、失敗したリリースに対する改善責任を明確にし、ニーズが満たされるまで改善要件を提示します。

組織は、適切な手段を通じて情報セキュリティ ポリシーを関係者に公開し、セキュリティ ポリシーに従うことの重要性と、SMS およびサービスへのセキュリティ ポリシーの適用可能性を明確にする必要があります。 組織は、組織および顧客サービスのコンポーネントと、サービスライフサイクルにおける関連担当者の責任に関連するデータに基づいて潜在的なリスクを特定し、リスクに基づいて適用可能な情報セキュリティポリシーを選択し、文書へのアクセスを通じて関連担当者に情報を提供する必要があります。研修等 情報セキュリティポリシーを周知します。適切な人々には、組織内の人々、外部プロバイダー、内部プロバイダー、その他の関係者が含まれます。

1. 環境の確立には、主にリスク評価の範囲、目的、評価基準の明確化が含まれます。リスクレベルのルール、資産、脆弱性、脅威のリスク割り当てルール、等 リスクの特定には、資産の特定、脅威の特定、脆弱性の特定が含まれます。 リスク分析には、資産、脅威、脆弱性間の関係の確立、リスクの可能性と影響の計算が含まれます (8.5.1.1 の変更影響分析方法を参照)。 リスク評価とは、リスク レベルのルールに従ってリスクをランク付けすることを指します。 リスク処理とは、リスク受容レベルとリスク選好に基づいて受容可能なリスクと受容できないリスクを判断し、コスト、利益、緊急性などを考慮して受容できないリスクに対する安全対策を選択し、処理の優先順位を設定することを指します。 2. リスク処理計画とは、取り扱うリスク、管理戦略、対応策、責任者、処理時間、残留リスクなどを含む安全対策を選択した後の作業計画です。 3. 安全管理措置を導入した後は、サービスの構成関係（8.2.6）に従って、サービスと情報資産（データを含む）との対応関係を事前に確立し、サービスの可用性と同様のアクセスパス（8.7. 1) アクセスパス上のすべての資産に対して以下の監視、評価、レビュー作業を実行する必要があります。 1. ネットワークセキュリティのエリア分割、セキュリティ機器の配備、境界セキュリティ対策の配備など、ネットワークセキュリティのアーキテクチャと設計が一貫している。 2. セキュリティ機能の設定は、セキュリティ ポリシーの要件と一致している必要があります。 3. 対処すべき資産の脆弱性が修復される。 4. 既知の脅威は封じ込められています。 5. 新たに特定された脆弱性またはパッチが適用されていない脆弱性については、侵入テスト手法を使用して、脅威による悪用の難易度が許容レベルを超えているかどうかを検証します。 6. サービスまたは顧客のビジネス システム全体が、ネットワーク セキュリティ レベルの保護要件など、国家または業界の規制要件を満たしていること。

1. インシデントの抽出、記録、分析と委任、処理、アップグレード、解決と終了などを含む、情報セキュリティ インシデント処理プロセスを管理します。これらの内容は、インシデント管理 8.6.1 の関連内容を参照して実装できます。 2. 情報セキュリティリスクに基づいて情報セキュリティ戦略を決定し、リスクと戦略に基づいて情報セキュリティ管理策を選択、導入、運用し、情報セキュリティリスク処理計画を策定します。 3. 情報セキュリティインシデント報告書を定期的に作成し、関係者に提出します。情報セキュリティインシデントレポートの主な内容は次のとおりです。 1) インシデントの発見時期、資産、および影響。 2) インシデントの原因、つまり脆弱性と脅威の状況の分析。 3) イベントの処理プロセスと結果。 4) 出来事に起因する変化。 5) 発生頻度の低減、被害の軽減、再発防止のための改善策など、原因と改善策の概要。 6) 必要に応じて責任を負い、罰する。