基幹システム（SAP）のバージョンアップで必要なこと（その３）
こちらの記事では、基幹システム（SAP）のバージョンアップで必要となるタスクについてまとめました。今回の記事では最初のタスクとなっていた「スコープの確認」の中の「2. SAP バージョンアップ」、「3. 周辺システムバージョンアップ」、「4. SAP GUIバージョンアップ」にて検討するポイントについて見ていこうと思います。
１．スコープの確認
１．ＨＷリプレース
２．SAPバージョンアップ
３．周辺システムバージョンアップ
４．SAP GUIバージョンアップ
SAP バージョンアップ目的の確認
まずはSAPのバージョンアップを行う目的を確認することが重要です。目的が延命のみであれば、FIやCOなど業務モジュールのバージョンアップは不要であり、やらない方がよいです。
FIやCOなどの業務モジュールをバージョンアップすると以下の箇所に影響が出ます。
-アドオンモジュールの修正が必要
-ホワイトボックステストが必要
-業務ロジックが変更になり、テスト時に単純な新旧比較ができない
一方でNetweaverやBasisモジュールのバージョンアップのみをスコープとした場合は以下の点に影響を絞ることができます。
-パフォーマンス
-認証、データ連携など業務モジュール以外の基盤モジュール
-ブラウザへの対応
Enterprise Portalを使用している場合はIEのサポート切れについても注意する必要があります。IEのサポート終了は2022 年 6 月 15 日ですので、これを機にChromeもしくはChromium Edgeに対応するバージョンを選定しましょう。
また、Chromium Edgeの対応とNetweverのサポート期限を考慮するとNetweverの7.54 SP4以上を選択した方がよさそうです。7.54は2027年12月31日までサポートされますが、7.3以下だと長くても2021年12月31日にサポートが切れてしまいます。
周辺システムバージョンアップ
SAPの導入時には夜間処理のスケジュール管理のためのジョブスケジューラや他システムとの連携のためのデータフォーマット変換システム、帳票システムなども同時に導入されているかと思います。
これらの周辺システムも同時にバージョンアップを行うか検討しましょう。
システムごとにバージョンアップを行うと連携テストを都度、行う必要がありますので、SAPのバージョンアップに合わせて実施することを推奨します。
スコープの定義とは少し話がそれますが、周辺システムもまとめてテストしてもらえるベンダーさんを採用した方がよいです。コストが割高になる可能性がありますが、連携テスト時に複数ベンダーのスケジュールを調整しながら進めるのは至難の業です。
また、複数ベンダーが入ってくるとスケジュールが遅延した場合にどちらの責任なのかが曖昧になります。
複数ベンダーが入った時の連携テストは下記のように複雑になります。
前提：
Aベンダー：ジョブスケジューラ担当
Bベンダー：データ変換機能担当
Cベンダー：SAPバージョンアップ担当
工程：
Aベンダー、Bベンダー、Cベンダーの構築スケジュールおよびテストスケジュールを調整
Aベンダーがジョブスケジューラのインストールおよびジョブ定義の移行を実施
Bベンダーがデータ変換定義を移行
Aベンダーがジョブ実行を実施
Bベンダーがデータ変換結果を確認
CベンダーがSAP上のジョブ実行結果を確認
Bベンダーのデータ変換で不具合が発覚
CベンダーのSAP上のテストを保留
他システムの対応
SAPをバージョンアップすると、SAPとデータ連携を行っていたシステムも何かしら対応が必要になってきます。
例えばSAPのバージョンアップとともにホスト名が変わった場合、データ連携を行っていたシステム側でもどのSAPと連携するかの連携定義にてホスト名を修正する必要が出てきます。
他システムのテストをバージョンアップを行うベンダーさんにお願いするのは難しいです。他システムのテストは内製で対応するとしても、テストのスケジュール管理や他システムの管理者とのスケジュール調整はPMとしてベンダーさんにお願いする方がよいと思います。
話が脱線しますが、他システムとのデータ連携を設計する場合は双方向のデータ連携を行うのではなく、必ず一方のシステムがトリガーとなってデータ連携を行うシステムを構築すると今後のメンテナンスがしやすくなります。
例えば、データ連携基盤というサーバを1台立てて、他システムに対してデータをPullで取りにいったり、Pushでデータを送り込むようにしておきます。こうすることでデータ連携の改修やテストを行う場合でも、データ連携基盤のサーバだけ対応し、他システムは変更なしという対応がとれます。
SAP GUIバージョンアップ
SAPシステム本体のバージョンアップを計画すると同時にクライアントツールであるSAP GUIのバージョンアップも忘れずに対応する必要があります。
SAPのサポート期限は注意深く確認しているのに、SAP GUIのサポート期限は気づいたら切れていたというのはよくあることなのかなと思います。
また、RFPにSAP GUIのバージョンアップ対応をスコープに含めておらず、内製で対応しないといけないということも出てきますので、スコープに含めるよう注意しましょう。
SAP GUIの利用者が多数の場合は配布方法も考える必要があります。ユーザにインストーラを手渡して、マニュアル通りインストールしてくださいと伝えるのはトラブルの元になりますので、SAP GUIのインストールを自動化するモジュールを作成した方がよいです。
また、SAP GUIのインストールはどの機能をインストールするか、SSO機能を有効化するかどうかなどによって、意外と複雑になります。現行の設計書が整備されていない場合などは現行調査もスコープにいれることをお勧めします。
まとめ
今回は下記の「2. SAP バージョンアップ」、「3. 周辺システムバージョンアップ」、「4. SAP GUIバージョンアップ」について紹介しました。
スコープ定義で抜けもれがあると、プロジェクトの中盤で「スコープに入っていないので対応できません」とベンダーさんから言われてもめることが多いです。ですので、スコープの定義は慎重に抜けもれなく行いましょう。
この記事が気に入ったらサポートをしてみませんか？