この特集のトップページへ
Chapter 3:データストア層の構築

head1.gif 3.1 構築するアプリケーションモデル

 まず,本連載でサンプルとして扱うビジネスアプリケーションモデルを決めておく。本連載では,Fig.3-1に示すようなビジネスアプリケーションを構築するものとする。Fig.3-1を見ればわかるように,ここで扱うサンプルは,在庫ならびに発注の管理を目的とするビジネスアプリケーションである。

Fig.3-1 サンプルアプリケーションのモデル

fig3_01.gif

head2.gif 3.1.1 業務内容
 サンプルアプリケーションを利用する組織は,企業顧客に対して製品を販売する中規模の企業である。この企業では,「製品の販売」という業務に,「営業部」「製品管理部」「経理部」という3つの部署が介在する。具体的には,営業部のメンバーが顧客の発注に基づき伝票を起票すると,その伝票が製品管理部に渡る。伝票を受け取った製品管理部のメンバーは,伝票に基づいて製品を発送する。製品が発送されたあと,経理部のメンバーがその伝票を集計し,請求書を発行する。これが,この企業における基本的な製品販売の流れである。

 各部署の業務分担を,もう少し具体的に示しておこう。なお,本来であれば,要求仕様を策定するためにも,現状システムをもっと緻密に分析することが求められる。しかし,本稿は設計手法の解説が目的ではないので,ここではこの企業が採用している業務形態の大枠を理解していただければ十分である。

○営業部

 営業部のメンバーは,まず,顧客の発注に基づいて伝票を記述する。いかなる場合にも,伝票を起票するのは,営業部のメンバーであるものとする。

 営業部のメンバーが起票した伝票は,上司に送られる。上司は,その伝票の内容をチェックし,問題なければ承認する(紙の伝票でいうと,上司が判子を押した状態となる)。承認された伝票は,製品管理部に送られる。もし伝票に不備があれば,上司は伝票を却下し,起票者に戻す。

 ただし,すべての伝票について上司の承認を仰いでいたら,営業効率が低下してしまう。そこでこの企業では,一定額以下の伝票は上司の承認を必要とせず,担当者の権限で直接承認し,伝票を製品管理部に送る仕組みを備えるようにする。

 ところで,Fig.3-1には示していないが,営業部のメンバーは顧客情報の登録も担当している。顧客情報の登録とは,顧客の名前や住所,電話番号などをデータベースに登録することである。営業部のメンバーが登録した顧客情報は,製品管理部や経理部から参照され,製品の発送や請求に利用される。現実世界の企業では,特に大口の取引については顧客情報の登録に先だって,相手先の信用調査などを実施することも多い。しかし,本稿はサンプルということもあって,そこまでは実装していない。

○製品管理部

 製品管理部は,製品の在庫管理,および伝票に基づく製品の発送を担当する部署である。製品管理部の作業内容は,次の3つから構成されている。

1)製品登録
 取り扱い製品を登録する。登録する情報には,製品の名前,価格などがある。現実世界における企業では,製品の名前や価格は製品管理部が決めるのではなく,営業部などほかの部署も絡んで定められることが多い。この企業でも,ご多分に漏れず営業部と製品管理部が事前に会議を開いて,製品の名前や価格を決定する。この決定に基づいて,営業部が販売戦略(キャンペーンなど)を定め,それに応じて製品管理部が在庫を確保することになる。なお,会議で決まった製品の名前や価格などは,製品管理部のメンバーがデータベースに登録する。
2)入荷処理
 製品の入荷処理をする。具体的には,いつ,どのような製品が,いくつ入荷するのかを登録する。このサンプルでは,「いくつ入荷した」という事実を登録するだけではなく,「何月何日にいくつ入荷予定」という予定も登録できるようにする。このようにすることで,営業部のメンバーは,その時点で在庫が揃っていなくても,いつまでに在庫が揃うのかを判断できるため,納期を考慮して営業活動を進めることができる。
3)発送処理
 営業部から回ってきた伝票に従って,製品を顧客に発送する。発送が完了したら,伝票を経理部に回す。

○経理部

 経理部は,製品管理部から送られてきた伝票を任意の期間で(相手の締め日などに合わせて)集計し,請求書を作る。作成した請求書は顧客に送付し,請求額に対応する顧客からの入金を確認する。

prevpg.gif Chapter 3 2/22 nextpg.gif