システム構成は、ライフサイクルを念頭に、TCOで考えよ

システム構成に関して異なるポイントを紹介します。ローカル要件としたものをどのように扱うかと言うポイントです。
ERP、特にSAP R/3を複数拠点に導入する場合は、システム構成を慎重に検討しなければなりません。
ローカル要件が、標準機能で対応できる場合、既存のアプリケーションを使用する場合は、あまり問題にはなりません。問題となるのは、アドオンを開発して対応するという方針を立てた場合です。


1台のサーバーで複数拠点をカバーする場合、拠点をどの組織項目で識別するかを決定し、すべてのアドオンプログラムで拠点による処理を分ける必要があることは、理解できるでしょう。
この開発標準化方針を決めずに導入した場合、後で大幅な手戻りが発生します。
拠点ごとにサーバーを立てる場合は、最初は問題ありません。しかし、導入拠点が増えるごとに台数が増加し、アップグレードも1度ではすみません。すべての拠点のアップグレードを完了するまで2年以上もかかる場合もあります。また、管理するサーバー台数の増加によって、悲鳴を上げている顧客もよく見かけます。
A化成は、事業部ごと、工場ごとにサーバーを立てて、導入することにしました。すべてのビジネスプロセスが異なり、標準化できないと当初考えての導入でした。
国内の導入を終え、海外拠点導入に移る時に、全社的に費用削減方針が出て、それに対応しなければならない事態となりました。
拠点ごとにビジネスプロセスが異なる。標準化できない。アドオン開発量も非常に多い。サーバー台数を集約するにしても、アドオンプログラムの改修は必至です。
いろいろと方法を検討しましたが、結局、アドオンプログラム改修のプロジェクトを発足させ、サーバーの集約をすることになりました。
同じころ、サムソンも同様の問題を抱えていました。サムソンの場合は、拠点ごとに導入をしているものの、ビジネスプロセスは似通っていました。似通ったビジネスプロセスを標準化させることによって、地域別にサーバーを集約して行きました。
両者とも、将来のニーズを考慮し、柔軟に対応できるようなシステム構成を十分検討した上で、導入に取り掛かれば、問題を最小限にできたのではないでしょうか。
今月は、両極端のシステム構成例をあげて説明しましたが、どちらが良くて、どちらが悪いと言う問題ではありません。その企業に合ったシステム構成を採用しなければなりません。その時、導入の目的は何か、いろいろなシステム構成の長所、短所を検討すること、などを予め行っておくことが重要となります。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*