まず答えは、境界が書き込まれずに想定される場合、遷移は失敗するということです。
契約に「IT 運用の管理」を盛り込むだけでは十分ではありません。安定したサービスは、システム、場所、時間、アクセス、依存関係、責任、受け入れ方法を一つ一つ定義します。そうしないと、同じインシデントがクライアント チーム、サービス プロバイダー、製品ベンダーの間で発生しますが、各当事者はそれが別の場所にあると信じています。価格や SLA 目標を比較する前に、次の 12 の質問に答えてください。
1. サービスとビジネスの優先順位
- どのビジネス アプリケーション、インフラストラクチャ コンポーネント、サイト、ユーザー グループが含まれますか?製品、バージョン、環境、ビジネス所有者を記録します。
- 収益、生産、または法定活動に直接影響を与えるサービスはどれですか?各重要度レベルには適切な回復目標とエスカレーション ルートがありますか?
- 明示的に除外されるものは何ですか?生産設備、OT、建築設備、大規模な開発および未承認のサードパーティ システムは、協会による範囲に入るべきではありません。
2. アクセス、資産、依存関係
- プロバイダーは実際にどのような監視、ログ、管理、およびリモート アクセスの権限を受け取り、誰がそれらを承認しますか?
- 資産リスト、構成関係、インターフェース、バッチプロセス、バックアップ、サプライヤー契約は完了していますか?そうでない場合は、限定された検出フェーズから始めます。
- クラウド プロバイダー、ソフトウェア ベンダー、通信事業者、その他のサプライヤーに属するものは何ですか?ケースをオープンし、エスカレーションし、変更を承認できるのは誰ですか?
3. 運用モデルと対象範囲
- サポート時間はどのタイムゾーンで定義されますか?休日、営業時間延長、オンコール対応、オンサイトアテンダントには別の条件がありますか?
- インシデント、問題、変更、リリースの所有者は誰ですか?重大なインシデントを宣言し、伝達し、終結させるのは誰ですか?
- チケットの優先順位はどのように設定されますか?また、有効なリクエストとは何ですか?優先ラベルだけでなく、ビジネスへの影響と意思決定基準を定義します。
4. 知識、人材、改善
- どの文書、録音、シャドーイング、リバースデモンストレーションが必要ですか?新しいチームが独立してパフォーマンスを発揮でき、退任するチームがそれを確認した場合にのみ、知識が移転されます。
- クリティカルスキルは一人に依存しますか?代替品を定義し、補償範囲を残し、プロバイダーのバックフィルを行います。
- 月次レビューでは、チケット数以外にも、再発する問題、根本原因、バックログのリスク、変更の成功、および名前付きの改善アクションもカバーされますか?
実際の 30 日間の移行シーケンス
- 第 1 週: 範囲、所有者、アクセス条件、資産、既知のリスクを確認します。欠落情報記録簿を作成します。
- 第 2 週: ナレッジ セッション、チケット分類法、エスカレーション マトリックス、運用チェックリストを完了します。影の重要な作品。
- 第 3 週: ドキュメントとアクセスのギャップを埋めながら、新しいチームに監督の下で実際のタスクを実行させます。
- 第 4 週: リバース デモンストレーションを実行し、未解決のリスクを確認し、移行を受け入れます。受け入れられた範囲のみが定常運用に移行します。
2 つの提案を比較する方法
月額料金と応答時間だけを比較しないでください。より良いテストとは、スコープが監査できるかどうか、所有権が名前付きロールに及ぶかどうか、依存関係が可視化されているかどうか、移行の前提が現実的かどうか、変更に商用メカニズムがあるかどうか、レポートが改善を促進するかどうかなどです。境界があいまいな安価な提案は、多くの場合、最初の大きなインシデントが起こるまで実際のコストが先送りされます。
Tech Alliance から開始できる場所
システム、サイト、依存関係、適用範囲、および責任をマッピングする、限定された操作の検出から始めることができます。そこから、どのインフラストラクチャ、アプリケーション、サイトサポート、または共同管理されるアクティビティが正式なサービス範囲に入ることができるかを確認します。当社は、未検証のプラットフォーム、24 時間対応、無制限のチケットなどを事前に約束することはありません。