岩井 孝夫
佐藤 三智子

 情報システムの形態には集中処理と分散処理があり,それぞれメリットとデメリットがある。集中と分散の双方があることを理解した上で,最も効果を上げる手段を多角的にどうとるかを決定する必要がある。その上で分散化の大前提として,最低限の管理標準の順守や,システム担当部門への状況報告の義務付けが必須となる。社内の各部署が自由にシステム化を進めても,情報の管理が阻害されないようにするためである。

 情報システムを「集中」か「分散」かの二者択一で単純に考えてはならない。従来なら集中処理しか選択の余地がなかったものが,手段として分散処理も取れるように多様化したと受け止めるべきである。すなわち,情報システムを導入するにあたって,(1) 集中処理の継続,(2) 分散処理への全面転換,(3) 集中処理と分散処理の併用,というように選択肢が拡大したと考える必要がある。

 さらに「集中か分散か」の検討対象は,マシンの配置だけではなく,システム開発や運用の体制,情報の管理など広範囲にまたがる。基本的な考え方は,「処理は分散,管理は集中」であろう。たとえ開発や運用を分散させていく方向であっても,情報化計画やコード体系,利用状況の把握,標準化推進といった事項については集中して管理しなければならない。

集中/分散の壁 (1)
分散後4年でバラバラに

 中堅メーカーA社は4年前から,営業部門や製造部門にオフコンを分散配置し,各部門のオフコンで基幹業務を処置している。以前は経理部に設置したオフコンですべての業務を集中処理していた。しかし,そのオフコンが能力不足になった時に,営業部門や製造部門から,各部門の事情に合わせて休日運転をするなど,独自の運用をしたいという強い要請が出た。このためオフコンを分散配置したのである。

 ただし,情報システム全体についてはこれまで通り,経理部が統括すること,各部署でシステム化を勝手に推進しないことを申し合わせた。

 その後,4年あまりは大きな問題はなかったが,98年に入って「全社の情報を活用するシステムの構築」が大きなテーマとして浮上した。そこで,経理部が中心となって営業部門と製造部門のメンバーを入れたワーキング・グループを作り,検討を開始した。ところが,検討の結果,各部門でそれぞれ勝手なシステム化が進んでいたことが明らかになった。

 アプリケーション・ソフトを見ると,各部門の都合の良いように修正され,しかも修正記録が残っていない状態だった。たとえば,営業部門に移管した販売管理システムは,東京本社・大阪支社・名古屋支社といった各地の事情に合わせて,それぞれ別個のプログラムが作成されていた。しかも,貴重な入力データを蓄積・保管しておく点についても配慮がなされていなかった。

 システムの修正は,移管先の各部門の予算の範囲で実施することになっており,修正のりん議を情報システムの担当部門である経理部へ回すルールになっていなかった。

 コード体系もばらばらになっていた。顧客コードを見ると,物流出荷用,中元歳暮のリスト用,社内管理資料作成用,といった具合で目的別に5通りもあったほどだった。製造部門のシステムも同様の状態であり,全社のレベルで情報システムを眺めてみると,統一性のないバラバラの状態になっていた。

 これでは経営に役立つ情報活用どころではない。現状を認識した経理部のシステム担当者は,情報化ルールの策定,ドキュメントの整備,コード体系の一元化,といった対応策の計画を作るところから手を付けた始めた。A社はこうした足元を固める作業で手いっぱいで,肝心の新しい情報系システムの構想を立案する点については見通しすらたっていない。