いざアップグレードが決まると、SAP ERPの「New General Ledger」や「新償却エンジン」など、現行システムに導入していなかった“新しいこと”を検討するケースが多い。そのため、仮にプロジェクトスコープが決まっていても、その方針や目指すところが明確になっていないと、後から次々に新機能導入についての要望が上がってきて、徐々にプロジェクトの方向性がぶれてしまう。

　アップグレードの方式を2種に大別すると、現行機能の踏襲を前提にバージョンのみを上げるテクニカルアップグレードと、今まで足りなかった機能を付け加えるなど、業務上の効果を出すことまでを目指すファンクショナルアップグレードがある。業務ユーザーや連携するシステムとの調整などにおいて、前者と後者では必要工数や難易度が大きく異なるため、どちらを目指すのかという方向性を最初に決めることが非常に重要である。

プロジェクト後期に画面変更要望が多発

　アップグレードによってSAP ERPの操作画面には項目の増減やテキスト変更が多数生じることが多い。これらの変更内容は、残念ながらSAP提供のリリースノートやデルタ一覧でも網羅されていないため、「プロジェクト開始時に業務ユーザーに全ての変更ポイントを提示し、業務影響を確認してもらった上で対応の要不要を判断する」といったアプローチが取りにくい。

　そのため、業務ユーザーと事前に変更ポイントについての十分な調整が行われていないと、稼働直前のユーザーテスト段階になって「オペレーションミスを防ぐために、追加された項目を非表示にしてほしい」といった変更要望が多発し、対応期間が足りなくなるリスクがある。

　少しでもリスクを下げるためには、下記のような対応を取ることが有効である。

• 現行業務に致命的な支障がない限りは画面の変更を許容するという方針をプロジェクト開始時に定義しておく
• 新旧画面比較のタスクをプロジェクト序盤に設け、作成したツールで検知した画面差異を業務ユーザーに提示し、確認してもらう

　これにより新規項目の非表示化、旧テキストへの戻しといった変更要望があった場合の対応期間を確保し、後続フェーズのユーザーテストで変更要望が多発するといった事態を回避する。

本番稼働後に詳細データパターンによる不具合が頻出

　アップグレードは、標準／アドオン問わずSAP ERP全体のプログラムに影響を及ぼすため、改修規模に比べてプロダクトテストの準備工数が大きくなりがちである。業務フローなどの既存資料を基にテストコンディションを作成しようとしても、十分なデータパターンのテストコンディションを作成していく作業には大量の工数が必要となる上、資料が陳腐化している場合、誤ったテスト仕様書を作成してしまう恐れがある。

　さらに工数を掛けてテスト準備したとしても、業務フローには表しきれないデータパターンのみで発生する不具合が存在する。そのため、プロダクトテストでは潜んだ不具合を拾いきれず、本番稼働後になって詳細データパターンによる不具合が頻出する可能性がある。

　そこで、通常のプロダクトテストを実施した上で、現行業務を踏襲する範囲について新旧比較テストを行うことにより、品質向上を図ることが効果的である。新バージョンの環境に、本番で発生したのと同じトランザクションデータを一定の期間分投入し、その処理結果を比較することによって、テスト準備工数を抑えた効率的なテストが実現できる。

本番改修内容の反映作業がスケジュールを圧迫

　SAP ERPを導入済みの企業が大規模改修プロジェクトを実施する場合、現行保守環境とは別に開発環境を設けることが多い。この場合、開発期間中に本番システムに施した改修を開発環境に逐一反映させる必要がある。アップグレードの場合は、保守環境（旧）と開発環境（新）とのSAPのバージョンが異なることにより、保守環境で作成した改修を開発環境へそのまま適用することができない。そのため、本番の改修内容について個別に開発環境への反映方法を検討する必要がある。

　また、当然ながら開発環境側での動作検証も必要となる。反映方法の検討には、保守内容に精通した担当者と、開発内容に精通した担当者との密な連携が必要不可欠であり、また難易度も高く、動作検証にも相当量の工数が必要となる。

　プロジェクト期間中は可能な限り本番側の仕様を凍結しておくことはプロジェクト運営上の定石であるが、アップグレード時にはより厳密にその方針を順守し、本番の改修案件自体を抑制する必要がある。

　以上がSAP ERPアップグレード作業を難航させる課題とその対策である。SAP ERPを導入済みの企業であれば、新機能や各種法改正に伴うアプリケーション変更に継続的に対応するためのアップグレードが必要である。ただ、明確な改革テーマを伴うプロジェクトとは違い、アップグレードは、旧バージョンの保守期限が迫ってきたことのみをきっかけに検討が開始される場合も多い。そのためプロジェクトとしての方向性が定まりにくく、後になってぶれてしまう可能性が高い。

　プロジェクトの方向性が定まっていれば、前述したような課題が生じた場合でも、対応策は自ずと定まってくる。最も重要な鍵は「アップグレードとともに何を目指すのか」をいかに明確に定義し、プロジェクトのステークホルダーから末端のメンバーに至るまで浸透させるかである。