結論：移管の成否は、誰が何をどこまで持つかを稼働前に決められるかで決まる
Support・AMSの失敗は、技術者が足りないことよりも、対象システム、責任、アクセス、第三者依存、サービス時間と受入条件が曖昧なまま開始することで起きます。最初の見積り依頼には、少なくとも次の12項目を含めてください。
1〜4：対象と責任
- 対象システム、製品、バージョン、環境、本番・非本番の境界
- 対象拠点、利用者数、言語、現場対応が必要な場所
- 顧客、サービス提供者、既存ベンダーのRACIと最終意思決定者
- インシデント、問題、変更、リリース、問い合わせの区分と各責任
5〜8：アクセス、運用時間と依存関係
- アカウント発行、権限承認、MFA、VPN、ログ取得とアクセス取消の手順
- 通常サービス時間、祝日、オンコール、重大障害時の連絡と到着目標
- クラウド、通信、ハードウェア、ソフトウェアなど第三者契約とサポート窓口
- 個人情報、機密情報、越境アクセス、端末とデータ保存に関する制約
9〜12：知識移管、受入と改善
- 構成図、運用手順、FAQ、既知エラー、ジョブ、インターフェース、連絡網
- 未解決チケット、技術的負債、リスク、保留中の変更と今後のリリース
- 並行運用の期間、受入テスト、移管完了の判定者と差戻し条件
- 初回応答、解決、バックログ、再発、変更成功率など、目的に合う少数の指標
人月契約とマネージドサービスは同じではない
人月契約は主に利用可能な工数を買う考え方です。マネージドサービスは、合意した範囲の運用結果、プロセス、報告と継続改善に責任を持つ考え方です。ただし、どちらが優れているかではありません。範囲が変動しやすい初期段階は共同運用、安定した定型業務はマネージド、改修や導入は個別プロジェクトに分ける方が実務的です。
最初の30日で確認する成果
- 全関係者が同じ対象一覧とRACIを使っている
- 重大連絡とアクセス取消を含むエスカレーションが実地確認されている
- 未解決事項が所有者と期限付きで一つの台帳にある
- レポートが作業量だけでなく、再発・リスク・改善行動を示している
TACは、インフラ・ユーザーサポート、アプリケーションサポート、SAP AMS、日本の現場とアジアのリモートチームを組み合わせるITサービスを、個別の対象・責任・体制に基づいて設計します。すべての技術や24×7を一律に約束せず、まず範囲と移管条件を確認します。