技術的なアップグレードが完了したら、必ずドライランを実施することをお勧めします。本番サイトのコピーをアップグレードすることで、潜在的な問題を特定し、本番稼動前に解決することができます。また、アップグレードのリリース後、突然サポートリソースが必要になった場合に備えて、十分なサポートリソースを確保しておきましょう。
ステージ2：テスト
この段階では、経験豊富なテストチームが、ソフトウェアシステムが機能要件と非機能要件を満たしているかどうかを評価する。品質保証エンジニアは、ビジネスの使用シナリオを再現する環境を設定します。その後、単体テストを実行してから、より複雑なユニットの組み合わせをシステム自体でテストします。最後に、テスト結果の詳細を記したテストレポートが発行され、開発者や利害関係者と共有される。
この段階の最初に、QAエンジニアはテストケースを作成する。テストケースとは、その機能に対して期待される前提条件、入力データ、取るべきアクション、期待される結果と同様に期待される前提条件やアクションなど、特定の機能をどのように評価するかについての詳細な説明である。この時点での主なアウトプットの一つは、要求事項と関連するテストケースを結びつけるRTMである。
ステージ3：配備
コードとデータベースの問題がすべて解決されれば、新バージョンを完全に導入することができる。そのためには、変化に対する自然な抵抗を克服し、新しいソフトウェアとプロセスを採用するために、ユーザーの全面的な努力が必要となる。また、環境間でデータを移行する際、重要なプロセスを見落とさないためのセーフティネットとして、既存のERPを一時的に並行して稼働させ続けることも賢明かもしれない。
インストールやテストの段階と同様、アップグレードプロセスにおけるリスク管理は、プロアクティブに管理されるべきである。これは、潜在的な脅威を特定することから始まり、その評価と緩和策を計画します。これには、以下のようなリスクが含まれる：
ステージ4：ゴー・ライブ
どのようなテクノロジー・プロジェクトでも、本稼働、つまり配備の段階が最も重要であることは間違いない。それは、新しい 製品 開発、テスト、実行、監視、管理、そして社内外の利害関係者とのフィードバック・ループを何ヶ月も、あるいは何年もかけて行うことが多い。
移行計画やハンドオフ計画を作成し、すべてのユーザー受入テスト項目を終了させるか、さらなる対応を通知するなど、本稼働から保守・サポートフェーズへのスムーズな移行を確保するために、事前に検討を開始する。また、ゴーライブ期間中に緊急の問題解決やエスカレーションされた状況が発生した場合に備えて、緊急連絡先リストを作成します。
このステップの一環として、アップグレードがユーザーにどのような影響を与えるかを評価し、影響を受けるすべての関係者がその意味を理解していることを確認することも不可欠である。そして、この情報を社外に伝えなければならない。
新しいデジタル資産管理システムへの移行が始まったら、継続的な問題を監視し、発生した問題をサポートすることが不可欠です。効果的な方法の1つは、本稼働期間中に定期的な総括会議を予定し、問題が発生したときに対処し、今後のアップグレード時に改善するための教訓を共有することです。また、これらのミーティングにプロジェクトチームのメンバーを参加させ、得られた教訓を共有し、次回に向けて開発すべき分野を特定することもお勧めします。
この本番稼動後の段階では、予期せぬ問題が発生した場合に対処するために、アップグレードの範囲にもよりますが、追加のサポート・リソースが必要になる場合もあります。これには、優先順位の高い問題に対するテクニカル・サポート、プロセスの決定を支援するサブジェクト・マター・エキスパート、新規ユーザーや経験の浅いユーザーに対するスーパー・ユーザー／チャンピオンなどが考えられます。
