システム構成は、ビジネス上の影響も考慮せよ

導入戦略の中のシステム構成をどのように考えるかを検討します。
システム構成とは、導入しようとするパッケージ、或いは、開発するアプリケーションをどのような環境で実現するのか?メインフレームで実現するのか、クライアントサーバーで実現するのか?
という課題が必ず浮上します。
SAP R/3を例に取れば、メインフレームにも、クライアントサーバーにも対応していますが、特に、私が経験したプロジェクトでは、クライアントサーバーで実現しながら、種々問題点を抱えたものが少なくありませんでした。


考えるポイントは、
1. 導入するサーバー1台ですべての拠点をカバーするのか
2. 拠点ごとにサーバーを立てるのか
3. 業務プロセスごとにサーバーを立てるのか
を決定することです。
サーバー1台で対応できるかどうかは、システム的な要求水準から決定します。例えば、バーフォーマンス。受注入力件数、MRP処理時間、データ量等から考えます。
特に、グローバル展開する場合は、時差を考慮して、運用のことまで考えねばなりません。
先週も紹介したある外資系コネクターメーカの話の続きです。
さらに仔細を聞くと、日本の出荷ピーク時に出荷伝票がプリントアウトされず、出荷作業が滞っているという問題がありました。
この会社では、サーバーは日本にはなく、米国本社で全世界をカバーしている環境で運用していました。ネットワーク環境を調査しても、問題はありませんでした。導入自体は、米国本社が主体となり、実施されたものでした。
何が原因かわかりますか?
ビジネス的には、ちょうど、日本の出荷作業ピーク時(午後4時頃)が米国では、夜間となり、米国の工場で、MRPを回している最中と重なっていました。
問題が社内に留まるのであれば、まだ影響が少ないと言えますが、出荷できないとなると、顧客に迷惑をかけるし、ビジネス上の影響も大きなものがあります。
早急に解決しなければ、この会社にとって、ビジネスを失うことになるかもしれません。
また、サーバーを調査すると、メモリ関係がダメでした。また、他の設定もインストール時のもので、チューニングされていませんでした。いわば、死に体でした。
この状況をSAP Americaが、運用に耐えられないと、赤信号の点ったレポートを提出していることが、後でわかりました。
この会社の場合、出荷伝票のプリントアウトを前もってやっておく等の対応で解決しましたが、結局、生産形態への対応のこともあって、システムのアップグレード時に、サーバーを日本に設置し、日本だけの処理を行うことになりました。
この話は、尾ひれがついて、日本の状況を見て、シンガポール子会社が導入を拒否したとのことです。
このような状況に陥ってしまうと、何のための導入かわからなくなってしまいます。
導入をIT関係のスタッフのみで行う危険性がここにあります。

コメントを残す

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

*