サービスサポートおよび運用

4.1 概要

本項は、Providerがプラットフォームに対して日常的なサポートサービスを提供するための運用サポートの枠組みを定義します。インシデント管理、チケットライフサイクル管理、予防保守、技術エスカレーション、運用変更管理のための構造、プロセス、および責任を定めます。

すべてのサポートプロセスはITIL 4のベストプラクティスガイドラインに整合し、Providerのオムニチャネルサポートモデルを活用して、すべての通信チャネルにわたり、迅速で、追跡可能かつ文脈情報に富むサービス提供を確保します。

サポートサービスは本番環境に適用され、Commercial Contractで明示的に合意された場合にはステージング環境にも適用されます。Providerは文書化されたサポート手順を維持し、合理的な要求があればCustomerに提供しなければなりません。すべてのサポート活動は、プラットフォームの組み込みチケットシステムを通じて記録・追跡され、ProviderとCustomerの双方にエンドツーエンドの可視性を提供します。

4.2 Provider Service Desk（PSD）

Provider Service Desk（PSD）は、Customerが起票するインシデント、サービス要求、問題、変更要求を含む、すべての技術サポート関連チケットの記録、管理、および解決を行う単一窓口です。PSDは、形式化されたチケット起票、リアルタイムメッセージング、従来の通信チャネルを単一の追跡可能なサポートワークフローに統合するオムニチャネルサポートモデルを運用します。PSDは、すべてのサポートおよび保守サービスについて、Customerの指定IT担当者と連携します。

4.2.1 組み込みチケットシステム

プラットフォームには、ProjectVIEW ERPアプリケーション自体の中にネイティブな組み込みチケットシステムが搭載されています。この統合ITSM機能により、認可ユーザーはERP環境を離れることなく、プラットフォーム内から直接サポートチケットを起票、追跡、および管理できます。組み込みチケットシステムは、以下を提供します。

• (a) アプリケーション内チケット起票: ユーザーはProjectVIEW ERPの画面内で直接チケットを起票でき、アクティブなモジュール、画面、ユーザー権限、関連データレコードを含む文脈情報が自動取得されます。
• (b) リアルタイムステータス追跡: ERP内の統合ダッシュボードに、未処理、対応中、解決済みの全チケットが、ライフサイクル全体の可視性、SLAカウントダウンタイマー、優先度表示付きで表示されます。
• (c) 双方向コミュニケーション: Customerと割当済みサポートエンジニア間のスレッド形式のやり取りはチケット内で行われ、完全な時系列監査証跡が維持されます。
• (d) 添付および証跡の取得: ユーザーはスクリーンショット、エラーログ、文書、画面録画をチケットに直接添付でき、エスカレーション時の文脈欠落を防止します。
• (e) SLA指標およびレポート: 応答または解決目標がしきい値に近づくと自動アラートを発する組み込みSLA追跡機能と、チケット件数、分類、解決実績に関するリアルタイムレポートを備えます。
• (f) ナレッジベース連携: チケットシステムはProviderの組み込みナレッジベース（wiki）にリンクし、チケット起票時に関連資料および既知の解決策を表示して、セルフサービス解決を可能にします。
• (g) 自動通知: 各チケット状態の遷移時（起票、確認、割当、更新、解決、クローズ）に、電子メールおよびアプリ内通知が送信され、すべての関係者に情報が共有されます。

組み込みチケットシステムは、すべてのサポート対応に関する記録システムとして機能します。電話、電子メール、WhatsApp、アプリケーション内のいずれのチャネルで最初に問題が報告された場合でも、SLA測定、監査可能性、およびコンプライアンスを確保するため、すべてのチケットは組み込みチケットシステム内で正式化されなければなりません。

4.2.2 オムニチャネルサポートチャネル

Providerは、以下のチャネルを通じてPSDへのアクセスをCustomerに提供しなければなりません。

4.2.3 WhatsApp Businessサポートチャネル

Providerは、各Customerごとに専用のWhatsApp Businessグループを設け、Customerの指定主要ユーザーとProviderの担当コンサルタントを接続します。このチャネルは、正式なチケットシステムを補完する迅速な非公式コミュニケーション層として機能します。WhatsAppチャネルには、以下のルールが適用されます。

• (a) 適用範囲: 簡易な問い合わせ、利用方法の案内、機能に関する確認、変更要求の可能性についての非公式な協議、および重大ではない問題の暫定報告。WhatsAppチャネルは正式なチケット起票の代替ではありません。
• (b) 正式化ルール: WhatsAppで連絡された事項のうち、正式な追跡、SLA測定、コード変更、設定変更、またはエスカレーションを要するものは、チケットとして記録しなければならず、ベンダーのコンサルタントが、特定後4時間以内に組み込みのチケット管理システムへ登録するものとする。顧客には当該チケット番号を通知するものとする;
• (c) SLA除外: SLAの応答および解決タイマーは、初回のWhatsApp連絡時ではなく、組み込みチケットシステムでチケットが正式化された時点で開始されます。
• (d) データ保護: 参加者は、WhatsAppを通じて個人データ、認証情報、データベース内容、または機密情報を共有してはなりません。Providerは、適用されるデータ保護法（参照：第17章）に基づくデータ取扱義務について、すべての参加者に説明しなければなりません。
• (e) 保存: WhatsAppメッセージは、Providerのデータ保持方針に従って保存されます。監査可能性の観点から、WhatsAppで行われた実質的な技術協議または決定は、対応するチケット記録に要約されなければなりません。
• (f) グループメンバーシップ: グループメンバーシップは共同で管理します。Providerは、要員変更があった場合、2営業日以内にグループメンバーシップを更新しなければなりません。Customerは、指定主要ユーザーの変更をProviderに通知しなければなりません。

4.2.4 PSDの運用時間および可用性

PSDは、すべてのチャネルでのチケット起票について1日24時間、週7日、年365日運用します。解決活動は、SLA応答および解決マトリクス（第3.6節）で定義された運用時間に従います。

UAE／ギリシャ／フィリピンの政府祝日は営業日計算から除外されますが、P1インシデントは祝日スケジュールにかかわらず対応されます。

4.2.5 PSDの責任

PSDは、以下を実施します。

• (a) Customerから報告されたすべてのインシデントおよびサービス要求を組み込みチケットシステムに記録し、固有のチケット参照番号と自動の文脈メタデータ取得を付与すること。
• (b) 各チケットに割り当てる優先度について、第3.5節で定義されるインシデント優先度分類に従い、Customerと合意すること。
• (c) eチケット受領後、顧客に受領確認を提供すること;
• (d) 適用されるサービスレベル目標内でサービスを復旧するために必要なすべてのエスカレーションを管理すること;
• (e) 相互に合意した間隔で、チケット管理システム、電話、電子メール、またはWhatsAppを通じて、進捗状況の定期的な更新を顧客に提供すること;
• (f) チケット解決時には、根本原因、実施した是正措置、およびチケットをクローズすべきか、あるいは追加対応が必要かを含む簡潔な説明とともに、顧客に通知すること;
• (g) 可能な場合は、まずチケットのリモートでの解決を試みるものとします。リモートでの解決が不可能な場合、プロバイダーは必要に応じて資格を有するエンジニアを顧客の施設へ派遣するものとします;
• (h) WhatsAppまたは電話で最初に連絡された問題は、4時間以内に組み込みのチケット管理システムへ正式に登録するものとします;
• (i) 組み込みのチケット管理システム内で、すべてのチケットのやり取り、ステータス変更、および解決活動について完全な監査証跡を維持するものとします。

4.3 チケットライフサイクル管理

すべてのサポート対応は、追跡可能性、説明責任、およびSLA目標への適合を確保するため、プラットフォームの組み込みチケットシステムを通じて管理される構造化されたチケットライフサイクルに従います。

このライフサイクルは、問題が最初に報告されたチャネルにかかわらず、インシデント、サービス要求、問題、変更要求のすべてのチケット種別に適用されます。

4.3.1 チケット起票

Customerがチケットを起票する際、PSDには少なくとも以下の情報を提供しなければなりません。

• (a) Customer名および契約参照番号（組み込みチケットシステム経由で起票されたチケットでは自動入力されます）。
• (b) 問題を報告する者の氏名および連絡先詳細
• (c) 問題の明確な説明。再現手順（インシデントの場合）または依頼内容（サービス要求の場合）を含みます。
• (d) 影響を受けたモジュールおよび影響を受けた認可ユーザー数
• (e) Customerが取得した診断情報、スクリーンショット、またはエラーメッセージ
• (f) チケットに対するCustomerの提案優先度

4.3.2 チケット処理ワークフロー

以下の手順は、チケットが初回起票からクローズまで処理される方法を定めるものです。

チケット再オープン: Customerが、チケットクローズ後5営業日以内に同じ問題が再発したと報告した場合、元のチケットは同じ優先度分類のまま組み込みチケットシステム内で再オープンされます。再オープンされたチケットは、SLA測定上は1件のインシデントとしてカウントされます。

4.3.3 チケット分類

チケットは、以下のカテゴリに分類されます。

4.4 技術エスカレーション

Providerは、適用されるサービスレベル目標内で解決が達成されない場合、または問題の重大性により上位の介入が必要な場合に、チケットを適切な専門性および管理権限へエスカレーションするための、構造化された技術エスカレーションマトリクスを維持します。

4.4.1 エスカレーションレベル

4.4.2 顧客起因のエスカレーション

顧客は、PSDに連絡してエスカレーションを要請することにより、いつでもチケットをエスカレーションできます。提供者は、エスカレーション連絡先マトリクスを少なくとも年1回、または人員に変更があった場合に更新し、更新後5営業日以内に最新のマトリクスを顧客に提供するものとします。エスカレーション連絡先マトリクスには、各エスカレーションレベルごとに氏名、役職、直通連絡先番号、電子メールアドレスを含めるものとします。

P1（重大）インシデントについては、初期対応で解決への道筋が特定されない場合、提供者は30分以内に自動的にレベル2へエスカレーションし、インシデントが未解決のままの場合は2時間以内にレベル3へエスカレーションするものとします。顧客の指定IT窓口担当者およびサービスデリバリーマネージャーには、すべてのP1エスカレーションがリアルタイムで通知されます。

4.5 予防保全

提供者は、顧客専用のプライベートソブリン環境内にあるすべてのプラットフォームコンポーネントに対し、月次予防保守を実施するものとします。予防保守は、サービス可用性または性能に影響が及ぶ前に潜在的な問題を特定し是正するため、予防的に実施されます。

4.5.1 予防保守の範囲

月次予防保守には、以下が含まれますが、これらに限定されません。

• (a) インフラ健全性チェック: 仮想マシンの性能監視、ディスク使用率、メモリ割り当て、CPU負荷分析、ネットワーク遅延評価；
• (b) データベース保守: インデックス再構築、統計更新、トランザクションログ管理、整合性チェック（DBCC CHECKDB）、およびストレージ最適化；
• (c) セキュリティパッチ適用: 提供者のパッチ管理ポリシーに従い、OS、ミドルウェア、データベースのセキュリティパッチを確認し適用すること（保守時間帯については3.1.3節を参照）；
• (d) バックアップ検証: バックアップジョブ完了の確認、バックアップ整合性テスト、およびリストア訓練の実施（四半期ごと）；
• (e) アプリケーション健全性: 稼働中のすべてのProjectVIEW ERPモジュールにわたる、モジュール単位の機能チェック、APIエンドポイント検証、統合監視、エラーログレビュー；
• (f) SSL/TLS証明書管理: 証明書の有効期限監視、更新、ローテーション;
• (g) キャパシティレビュー: 現在のリソース使用率を割当済みキャパシティと比較評価し、使用率が75%の閾値を超える場合はプロアクティブなスケーリング提案を行うこと。

4.5.2 予防保守レポート

各予防保守サイクルの完了後、提供者の保守エンジニアは予防保守レポートを3営業日以内に顧客へ提出するものとします。レポートには以下を含めるものとします。

• 保守作業の実施日時および所要時間;
  • 点検したコンポーネントおよび実施した作業；
  • 特定されたリスクまたは異常と推奨是正措置；
  • 現在のリソース使用率と割当済みリソース使用率の指標；
  • 今後のパッチおよび更新スケジュール；
  • バックアップ検証結果の確認。

4.6 変更管理

プラットフォームの構成、機能、またはインフラストラクチャーに対するすべての変更は、Production Environmentへのリスクを最小化するよう設計された正式な変更管理プロセスにより管理されます。変更は、ITILの変更管理ベストプラクティスに従って分類および管理されます。

4.6.1 変更分類

4.6.2 変更管理ワークフロー

通常変更および緊急変更はすべて、以下のワークフローに従います。

• (a) 要求: CustomerまたはProviderは、説明、業務上の正当性、影響を受けるモジュール、および希望実施日を含むChange RequestをPSD経由で提出します;
• (b) 評価: Providerは、技術的リスク、影響を受けるユーザー、ロールバック計画、見積工数、依存関係を含む影響評価を実施します;
• (c) 承認: Change Advisory Board（緊急変更の場合はService Delivery Manager）が変更を審査し、承認または却下します;
• (d) 実装: 変更はStaging Environmentで開発され、展開されます;
• (e) UAT: CustomerはStaging EnvironmentでUniversal User Acceptance Testingを実施します。UATには最低5 Business Daysが付与されます。書面による承認が必要です（3.3.1項参照 3.2.1);
• (f) 展開: CustomerによるUAT承認後、合意されたメンテナンスウィンドウ中に変更がProductionへ展開されます;
• (g) 実装後レビュー: Providerは展開後5 Business Daysにわたり変更を監視し、クローズ報告書をCustomerに提供します。

ロールバック: すべての通常変更および緊急変更には、文書化されたロールバック計画を含めるものとします。変更が計画外のサービス低下を引き起こした場合、提供者は問題を特定してから2時間以内にロールバックを実行し、直ちに顧客へ通知するものとします。

4.6.3 変更の監査可能性

プラットフォームの構成、コードベース、およびインフラに対するすべての変更は、提供者の変更管理システムに記録されます。各変更記録には、依頼者、説明、リスク評価、承認経路、実装日、実装エンジニア、テスト結果、および実装後の状態が含まれます。変更ログは、要請に応じて顧客に提供され、四半期サービスレビューに含まれます（3.9.2節参照）。

4.7 ソフトウェアリリース管理

Providerは、すべてのソフトウェア提供を、2つの本質的に異なる提供タイプを区別する管理されたリリース管理プロセスを通じて管理します。すなわち、Releases/Updates（漸進的、顧客固有、頻繁）とUpgrades（メジャーバージョン、製品全体、年次）です。この区別により、Customerの日常的なアジャイル提供がProviderのより広範な製品ロードマップと競合しないことが保証されます。

4.7.1 リリースおよび更新（増分版 例: v11.xx）

Releasesおよびupdatesは、プラットフォームの現在のメジャーバージョン内における漸進的な提供です（例: v11.01、v11.02、v11.15）。これらは、Customerの実装に固有の変更要求、バグ修正、構成調整、および小規模な機能拡張に対応します。Releasesは、Customerの運用サイクルに合わせたアジャイル実行手法を用いて提供されます。

アジャイルスプリント手法: Providerは、1スプリントあたり平均3 Business Daysの短期サイクルスプリントで運用します。各スプリントでは、スプリント計画時にCustomerと合意した変更要求、バグ修正、または構成変更の定義済みセットを提供します。スプリントサイクルは以下のとおりです:

リリース版数管理: 各漸進的リリースには、現在のメジャーバージョン内でセマンティックなバージョン番号が付与されます（例: v11.01、v11.02… v11.xx）。バージョン番号はスプリント提供ごとに順次増加します。Providerは、Platformを通じてCustomerがアクセス可能なリリースログを維持します。

4.7.2 アップグレード（メジャーバージョン 例: v11 → v12）

Upgradesは、プラットフォームの新しいメジャーバージョンを意味します（例: v11 → v12、v12 → v13）。Upgradesは、重要な機能拡張、新モジュール、UI/UXの再設計、新しいAPI/SDK、アーキテクチャ改善、および主要なCOTSバージョンアップグレード（例:.NET framework、SQL Server engine）を含む製品全体のリリースです。Upgradesはおおむね年1回リリースされ、新しいソフトウェアバージョン番号を表します。

メジャーアップグレードには通常、以下が含まれます。

• 新機能強化: 提供者の製品ロードマップおよびCustomer Advisory Boardのフィードバックに基づく機能追加、新しいモジュール機能、およびワークフロー改善；
• UI/UX改善: 画面再設計、使いやすさの向上、アクセシビリティ改善、およびレスポンシブデザインの更新；
• APIおよびSDK拡張: 新しい統合エンドポイント、強化されたWeb API機能、および更新されたソフトウェア開発キット；
• COTSプラットフォームアップグレード: 提供者の技術鮮度維持コミットメントの一環として、基盤技術（.NET、SQL Server、IIS）の新バージョンへの移行；
• セキュリティ強化: 新しいセキュリティ標準、暗号化の強化、および新たに出てくる規制要件への適合の実装。

4.7.3 統合リリース管理および展開プロセス

すべてのリリース（漸進的）およびアップグレード（メジャーバージョン）は、中央のリリース管理および配布プラットフォームであるPlatform Release Centreを通じて管理されます。Platformは以下の機能を提供します:

• (h) リリースカタログ: 各Customer向けに利用可能なすべてのリリースの完全なカタログで、アプリケーション別およびバージョン別に整理されています。各リリース項目には、リリース日、バージョン番号、新機能、修正、および既知の問題を説明する詳細なリリースノートが含まれます;
• (i) 認証ベースのアクセス: プラットフォームへのアクセスは、顧客の指定管理者に割り当てられた固有の認証情報により保護されます。アクセス権により、顧客がライセンスを受けたモジュールに適用されるリリースの表示範囲が決まります；
• (j) リリースノートおよび変更ログ: 各リリースには、最新の機能、機能性、およびバグ修正を説明するセマンティックかつ文脈的なコメントが付属し、公開前にProviderのReviewerによる審査および承認を受けます;
• (k) オンデマンド提供: リリースは、Customer管理者の承認を条件として、オンデマンドでダウンロード可能です。Providerは、新しいリリースが利用可能になった際にCustomerへ通知します;
• (l) 監査証跡: Platformは、各Customer環境でどのリリースが利用可能になり、ダウンロードされ、展開されたかの完全な記録を保持します。SaaS展開モデル: SaaS提供モデルでは、ProviderがCustomer専用のソブリン環境へのすべての展開を管理します。Customerが自らリリースをインストールすることはありません。展開プロセスは以下のとおりです:

4.7.4 End-of-Lifeおよびバージョン移行

ProviderのEnd-of-Life（EOL）ポリシー、バージョン移行ライフサイクル、移行サービス、再トレーニングプログラム、データ返却手順、およびサブスクリプション終了プロセスは、Chapter 10 — End-of-Life, Version Transition & Subscription Cessationに包括的に定義されています。Chapter 10は、General Availability（GA）からEOL告知、End of Engineering（EOE）、End of Life、および任意のExtended Supportに至るまで、バージョンライフサイクル管理のあらゆる側面を規定します。

本章の目的上、以下の要約が適用されます。Providerは、メジャーバージョンがEnd of Lifeに達する前に、少なくとも12か月前の書面通知をCustomerに行うものとします。移行計画、データ移行、連携の適用、再トレーニング、UAT支援を含むアップグレード支援は、追加費用なしでSubscription Termに含まれます。完全な条件、スケジュール、および手順は、10.1項から10.14項に定められています。

4.7.5 バージョン管理およびソースコードエスクロー

Providerは、以下を組み込んだGitベースのバージョン管理システムで、すべてのソースコードを管理します:

• Master Branch: 現在一般提供されているリリースを表す標準のDANAOSアプリケーション（「Vanilla Version」）;
• Client Branches: 専用ブランチとして管理されるCustomer固有の構成およびカスタマイズ。スプリントリリースはClient Branch上で開発されます;
• Working Clones: 安定した条件下でマージされ、新機能をMasterおよびClient Branchに組み込む開発者の作業コピー。すべてのコード変更は、Pull Requestによるピアレビュー、自動テスト、およびコード品質、ビジネスロジック、セキュリティの最良基準を含むProviderのプログラミングガイドラインへの準拠の対象となります。CommitおよびPushの実行後、ならびにPull Requestレビュー後、アプリケーションのバージョンは、責任あるプログラマー（またはAgile Team）によって、セマンティックかつ文脈的なコメントを用いて完全に正当化されます。Reviewerは、Providerのプログラミングガイドラインに基づいて変更を承認または却下します。ビジネスロジックは、各分野の専門知識を有するDANAOS Support Engineersによって追加で検証されます。

Providerは、適切な場合に、ソフトウェア展開のための継続的インテグレーション／継続的デリバリー（CI/CD）を実施します。CI/CDパイプラインは、GitリポジトリからStaging Environmentまでのビルド、テスト、および展開の各段階を自動化し、一貫性を確保して手動展開エラーを削減します。

Providerは、独立した第三者のEscrow Agentとソースコードエスクロー契約を維持するものとします。エスクロー預託内容、更新頻度、年次検証、開放条件、および開放時のCustomerの権利を規定する包括的な条件は、Section 9.14 (Source Code Escrow)に定義されています。Escrow Agentの手数料を含むエスクロー契約の費用はCustomerが負担するものとします（§ 9.14.4参照）。

4.8 IMAC/RDサービス

Providerは、継続的な運用サポートの一環として、Platform向けにInstall, Move, Add, Change, Remove, and Dispose (IMAC/RD)サービスを提供します。IMAC/RD活動は、StandardまたはNormal変更として管理され（4.6.1項参照 4.6.1）、以下の範囲に従います:

Subscription Termの範囲外となるIMAC/RD活動は、別途1人日単価で見積もられ、作業開始前に両当事者間で書面により合意されます。

4.9 エンタープライズアーキテクチャ指針

Providerは、システム統合、データフロー設計、技術整合性を含む、Platformに関するエンタープライズアーキテクチャ事項についてCustomerに助言します。これには以下が含まれます:

• (a) 統合アーキテクチャ: PlatformのネイティブWeb APIを介してProjectVIEW ERPをCustomerの既存のエンタープライズシステム（例: SAP、Oracle、銀行プラットフォーム、人事システム）に接続するための指針（2.5項参照 2.5);
• (b) データアーキテクチャ: 顧客専用のソブリン環境内でのデータフロー、データ移行計画、マスターデータ管理、およびレポーティングアーキテクチャに関する助言；
• (c) セキュリティアーキテクチャ: ネットワークセキュリティ、アクセス制御ポリシー、暗号化標準、および本フレームワークのPart Bに詳述されたセキュリティフレームワークとの整合に関するガイダンス；
• (d) 拡張性計画: ユーザー増加予測、データ量の傾向、およびモジュール有効化計画に基づく環境拡張のための事前推奨事項。エンタープライズアーキテクチャの指針は助言サービスとして提供され、第三者システムの設計、開発、またはサポートには及びません。アーキテクチャ上の推奨事項の実装は、当事者間で合意した別途のスコープ設定および費用算定の対象となります。

4.10 継続的サービス改善（CSI）

プロバイダーは、ITIL 4のプラクティスおよび最新の継続的サービス改善（CSI）プログラムを運用しています。これは、サービス品質、運用効率、および顧客満足度の継続的な向上を推進するために、AIOps手法と整合しています。CSIプログラムには以下が含まれます。

• AI支援によるトレンド分析: パターン認識と異常検知を用いた、インシデント件数、分類、再発問題、および解決時間の月次分析により、システム的改善をプロアクティブに特定すること；
• 根本原因の排除: クロスタケット相関分析に基づき、恒久的な修正によって再発インシデントの根絶を目指す問題管理活動;
• プロセス最適化: サポートプロセス、チケットワークフロー、エスカレーション手順、オムニチャネルサポートの有効性を定期的に見直し、解決時間を短縮してCustomer体験を向上させる;
• 顧客フィードバックおよび体験管理: 顧客満足度調査結果、四半期サービスレビューのフィードバック、WhatsAppチャネルの有効性指標をCSIレジスターに反映する;
• 技術更新: Customerに लाभ益をもたらすCOTS更新、セキュリティ強化、プラットフォーム最適化を能動的に特定する;
• ナレッジマネジメント: 解決済みチケットから得られたソリューションを組み込みナレッジベースに継続的に蓄積し、セルフサービスでの解決率向上と再発インシデント件数の削減を実現する。CSIレジスターはService Delivery Managerが管理し、各四半期サービスレビューで見直される（参照 3.10.2節3.9.2）。すべてのCSI施策は、特定から実装まで測定可能な成果とともに追跡される。Providerがサポート業務でAI支援ツールを採用する場合、その使用はEU AI ActおよびNIST AI Risk Management Framework (AI RMF 1.0)を含む適用可能なガバナンス枠組みに準拠しなければならない。

参考URL:

ITIL 4 Foundation – PeopleCert / Axelos ProjectVIEW ERP Ticketing System – DANAOS Projects WhatsApp Business Platform – Meta Azure Service Health – Microsoft NIST SP 800-88 Media Sanitization Guidelines NIST AI Risk Management Framework (AI RMF 1.0) EU AI Act – European Commission

4.11 プロセスレジスター

以下の表は、本章で定めるサービスサポートおよび運用プロセスの概要を示し、責任者、期待される成果、ならびに他章の関連プロセスへの相互参照を含みます。

役割凡例: P = Provider | C = Customer | PSD = Provider Service Desk | SDM = Service Delivery Manager | CAB = Change

Advisory Board | SC = Steering Committee

4.11.1 プロセス登録簿

4.11.2 RACIマトリックス

R = Responsible（実行） | A = Accountable（承認責任） | C = Consulted（協議先） | I = Informed（通知先） | — = 不関与

4.11.3 プロセスフロー — サポートおよび運用ライフサイクル