AMS移行とアプリケーション資産のベースライン
例示ユースケースであり、顧客事例ではありません。
当社が構築していないアプリケーションの引き継ぎです。資産を棚卸しし、範囲と重大度を合意し、知識を移転し、運用を始める前にサービスの基準を定めます。
課題
アプリケーションは動いているが、それを理解していた人は去り、あるいは現行ベンダーが撤退しようとしている。ドキュメントは部分的で、カスタマイズは記録されておらず、どの連携が重要なのかを誰も言えない。サポートはまず理解されない限り改善できない。
現在の進め方
新しいサポートチームがチケットキューと共有ドライブを引き継ぎます。ナレッジの移転は、引き継ぎ元のチームとの数回の通話で済まされます。重大度の定義、サービス時間、エスカレーション経路は旧契約から推定されます。最初の数か月は、インシデントを通じてアプリケーション資産を再発見することに費やされます。
シナリオを見る
ワークフローの例示です。字幕付き。
文字起こし
- アプリケーションは動いていますが、それを理解していた人はもういません。文書は部分的で、カスタマイズは記録されておらず、どの連携が重要か誰も言えません。
- 当社はアプリケーションを棚卸しし、サポートの範囲と時間を合意し、手順と不足を文書化してから、サービス開始時のベースラインを定めます。
- 把握の段階では本番環境に何も変更を加えません。オーナーがサービス開始前に定義を承認し、発見事項はオーナーが優先順位を付ける改善バックログに反映されます。
- 測定するのは資産のカバー率と未知のコンポーネントに起因するインシデントです。例示ユースケースです。貴社のケースについてご相談ください。
提案するワークフロー
- アプリケーション資産を棚卸しする。モジュール、連携、カスタマイズ、エージェント、およびそれらが稼働する環境を、記憶ではなくシステムから集めた証拠に基づいて把握する
- チケットを一件も受け付ける前に、範囲、重大度の定義、サービス時間、ベンダーへのエスカレーション責任を書面で合意する
- ナレッジをランブックと承認済みのナレッジベースに移転し、不足は隠さずに一覧化する
- サービスのベースラインを定める。現在のインシデント件数、解決時間、リリース頻度、既知のリスク
- 合意した定義のもとで運用し、発見事項を記録し、オーナーが優先順位を付けるための改善項目を提案する
人が判断を担う箇所
- 範囲、重大度、サービス時間、エスカレーション責任は、サービス開始前にオーナーが承認する
- 把握の段階では本番環境に変更を加えない。発見事項は記録し、その場で修正しない
- 改善バックログの優先順位はサポートチームではなくオーナーが決める
プラットフォームの対応付けは、この構想を評価しうる環境を示すものです。実際の実装は、設定、ライセンス、API、データ、権限によって異なります。効果は定性的に記載しており、数値による主張には文書化されたベースラインが必要です。