データウェアハウス中心アプローチで問題解決しようシステム部門Q&A(14)(3/3 ページ)

» 2004年10月29日 12時00分 公開
[木暮 仁,@IT]
前のページへ 1|2|3       

データウェアハウスを前提とした基幹業務系システム

 基幹業務系システムはデータウェアハウスのデータを維持するものだと解釈すると、基幹業務系システムの構築はかなり容易になります。

1. 基幹業務系システムの分担が明確になる

 基幹業務系システムの構築では、エンドユーザーのニーズを実現することに多くの労力を費やしますが、この体系では、最初に基幹業務系システムを検討するのではなく、まずデータウェアハウスにどのようなデータがあればよいのかを整理します。

 次に、そのデータを収集するのに、基幹業務系システムとして構築するか、エンドユーザーの自主管理に任せることができるかどうかを検討します。売り上げデータなどは基幹業務系システムで収集するでしょうが、市町村の人口や自動車台数のような外部資料から得るものは、エンドユーザーに任せればよいでしょう。商品区分や得意先区分などはグレーゾーンですが、典型的なものは基幹業務系システムで管理し、アドホック的なものはエンドユーザーに任せることもありましょう。また、将来的には基幹業務系システムに取り込むが、当面はエンドユーザーが行うというようにすることもありましょう。

 基幹業務系システムで収集すべき事項が決まれば、それをどのようにして収集するかがシステム設計になります。しかも、正規化したデータの更新ですから、これは比較的容易でしょう。

2. 名称や定義、マスタファイルが明確になっている

 データウェアハウスのデータを検討する段階で、各項目の名称や定義が明確になっているはずです。また、項目間の上位下位概念が明確になっているということは、ERモデルができていることであり、マスタファイルができていることになります。

 すなわち基幹業務系システムとは、事象によりデータが発生するイベントファイルのシステムだけを対象にすればよいことになります。

3. 統合したシステムになる

 とかく基幹業務系システムは、販売システム、購買システム、会計システムなど縦割りのシステムになりがちで、販売システムの得意先と購買システムの仕入れ先の体系が異なるので、会計システムでの売掛・買掛の相殺ができないなどの問題が発生します。

 ところがこのようなことは、データウェアハウスのデータを考えるときに、自然に気付くことですし、あまり苦労しなくても、当初から統合化が実現するでしょう。

フロントオフィスシステムとバックオフィスシステムの分割

 基幹業務系システムは、フロントオフィスシステムとバックオフィスシステムに分割できます。

1. 両者の特徴

 フロントオフィス業務とは、受注や出荷などデータの発生する分野の業務です。環境の変化に影響されやすく、しかも即応することが必要です。基幹業務系システムは情報検索系システムにデータを供給することが任務だといってきましたが、それ以外に、基幹業務系システムには「業務の仕方を規制する」という機能があります。環境の変化に即応するとは、業務の仕方を規制することだともいえましょう。処理体系の観点では、フロントオフィスシステムは多様な部門が多様な方法でデータを収集するのですから、分散処理形式になります。また、単に情報を収集するのではなく、その業務に関する多様な情報に基づいて行動するので、データマートと合わせて利用することも多いでしょう。

 それに対してバックオフィスは、フロントオフィスのデータを加工して在庫を計算したり、利益管理をしたりすることが目的です。それには定例的・定型的なものと非定例的・非定型的なものがありますが、バックオフィスシステムに要求されるのは前者であり、後者は情報検索系システムの分野だといえます。ですから、バックオフィスシステムは、経営環境の変化にはあまり影響されない特徴があります。なお、全社のデータを一覧的に処理することが必要ですので、処理形態は集中処理になります。

2. 分割すべき理由

 このように、両者はかなり異なる特徴がありますので、分割して考えるのが効果的です。

〇フロントオフィスシステムとワークフロー管理システム

 購入するときには事前に予算計上を行い、購買時には見積もり比較をして購入稟議を行い、承認決裁を得てから購買します。従来の購買システムでは、決裁を得てデータ入力をする段階からをシステム化していただけで、予算や稟議などのプロセスは手作業のままでした。ワークフロー管理システムを利用することにより、これらのプロセスをシームレスにシステム化することができます。

 このように、フロントオフィスシステムは、ワークフロー管理システムにより実現するのが効果的であることが多いのです。

〇ERPパッケージの導入

 ERPパッケージの導入では、カスタマイズをしないこと、対象業務での変化をしないことが成功のポイントであるといわれています。カスタマイズへの要求は入出力関連でのヒューマンインターフェイスが多い分野に出てきます。出力系はデータウェアハウス、入力系はワークフロー管理システムに任せて、ERPパッケージがカバーすべき範囲をバックオフィスシステムだけに限定することにより、カスタマイズを抑制することができます(「第6回 ERPのカスタマイズを最小限に抑えるには」参照)。また、バックオフィスシステムに限定することは、対象業務での変化が少ないことにもなります。

逆歴史的な情報システム体系

 歴史的には、基幹業務系システムから情報検索系システムへと発展したのに、この体系では、まず情報検索系システムがあり、それを実現するために基幹業務系システムがあるのだと、逆歴史的な立場に立っています。私は、これをパソコンの利用、グループウェア(コミュニケーション系システム)、インターネットなどにも広げて、「逆歴史的情報システム体系」として認識すべきだと主張しています。

 すなわち、インターネットに接続しているパソコンの利用がベースにあり、社内に限定された範囲で高度な情報伝達・共有手段としてコミュニケーション系システムがある。情報の中にはフォーマットされたデータを加工するものもあるので、それに特化したものが情報検索系システムである。そして情報検索系システムのデータをオーソライズした方法で収集するのが基幹業務系システムであるという考え方です。

逆歴史的な情報システム体系

 これには、ここで挙げたこと以外にも多くの効果があるのですが、それについては別の機会にさせていただきます(「情報システム利用形態の体系に関する考察」参照)。

この記事に対するご意見をお寄せください managemail@atmarkit.co.jp


筆者プロフィール

木暮 仁(こぐれ ひとし)

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査、ISMS審査員補など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」「情報システム部門再入門」(ともに日科技連出版社)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ