パッケージの場合はドキュメントの整備が必要
統合基幹業務システム（ERP）などのパッケージを利用したモダナイゼーションの場合は、一見、現行のIBM iのリソースを見ずに業務にあわせたフィット＆ギャップ分析を行い、フィットした仕様はERPの機能を使い、ギャップの部分はカスタマイズして仕様追加することで進められるように見える。が、機能のドキュメント化など、パッケージの機能と比べる現行業務が整備されていることが前提となる。
ユーザーによっては、これらが最新化されていない、もしくは整備されていないため、業務仕様の最新情報はIBM iのリソースの中にあるという場合がある。自社の情報整備を顧みずに行動を起こすと、現行の仕様のリバースなどの思わぬ追加コストがかかり、カットオーバーも大幅に遅延する場合がある。また、人手により完全にリバースしきれず、ギャップを抱える業務機能を移行できずにいるユーザーも少なくない。
段階的なリプレースやサブシステム利用にも注意
営業システムや人事システムなどにおいて、パッケージやクラウドサービスへの部分的なリプレースが増えている。機能強化は提供ベンダーによって継続されるため、ビジネスや世の中の変化にあわせた柔軟性が必要なサブシステムのモダナイゼーションとしては有効な手段だろう。また、さまざまな機能を段階的にIBM iの外に出していけるというメリットもある。
業務機能的に現行システムの独立性が高い場合は問題にならないが、サブシステムに跨る共通プログラムやデータが多く、各システムが複雑に結びつく場合は、外出ししたシステムとのトランザクションやデータ連携が必要となる。思わぬ連携システム追加やコスト増加に悩むユーザーもいることが現状である。
では、これらの問題をどうやって回避すれば良いのだろうか？
次回は「IBM i（AS/400）のレガシーの正体」をテーマに、まず、モダナイゼーションすべき対象を正しく特定して、今回の企画の主題である「新しい選択肢」につなげる前提を示したいと思う。
（第3回は10月下旬にて掲載予定）
- 阿野 幸裕（あの ゆきひろ）
- ジーアールソリューションズ
- モダナイゼーション事業部長
-
大学卒業後、トーメン情報システムズで、IBMメインフレーム、ミッドレンジコンピューター、UNIXなどのシステム開発を経験後、1995年よりSybaseやSASなどの外資系ソフトベンダーにてプリセールスエンジニアとして従事。
2020年4月から、その経験を生かし、ジーアールソリューションズに入社。以来、同社が独占販売権を持つカナダFresche solution社の製品を中核としたモダナイゼーション事業に参画している。
