はじめに
そもそも業務を遂行することは、業務にまつわる情報の管理と同義である。つまり、業務システムにおいては如何に顧客の業務と業務にまつわる情報のシステム管理を実現できるか?がポイントとなる。
ITの普及により、紙やペンという管理方法からデータでの管理に切り替えている会社が大半を占めている。これからの情報社会において顧客目線での業務と業務データのシステム管理はこれまで以上に必要となってゆく。
販売管理を例とした業務のデータ管理
では具体的にどのようにシステムと業務が絡んでいるのか、販売管理を例に挙げて説明する。
・オーダーシステム…受注処理において生み出された顧客の情報を管理する
・出荷情報システム…受注を元に出荷された情報を管理する
※オーダーを関係はあるものの、情報はイコールではない。そのためデータベースは異なる。
・売上情報システム…納品を元に計上した売上の情報を管理する。売上計上された情報から連携して請求書を発行する。
・請求書発行システム…どの客に、いつ、どの取引の請求書を発行したか管理する。
オーダー・出荷情報・売上情報システムはそれぞれ繋がりがあるものの、情報はイコールではない。同じ情報を管理しているわけではない以上、違うデータベースを使用する。
顧客の業務をシステムで管理することが我々ベンダーの目標であるが、断じて全ての業務を管理するわけではない。
重要なのは、その顧客において大事な業務はどれか・多くの金額が絡む業務はどれか・頻度が高い業務はどれか、といったことを分析し、どの業務の管理をシステムで行うべきかを判断することである。つまり、業務への影響が強いものを中心にシステムを考えていく必要がある。
全ての業務を管理するには考慮すべき点が多く存在し、費用の面からも更に高くなることが考えられる。顧客と相談しながら、システム化するものとそうでないものを切り分けていくことが大切である。
そこで、顧客がどのような仕事をしているか、という部分も知っておくとより良い。全てを知る必要はないが、知っているか・知らないかという差はやはり生じてしまう。業界ごとのビジネスモデルなどを事前に把握しておくべきという話はここに繋がる。
トランザクションデータとマスタデータ
トランザクションデータ
トランザクションデータとは取引(オーダー)ごとに固有の情報を指す。
具体的には、商品や数量、価格、受注先、出荷先、納期などが挙げられる。
これらは全ての取引に共通している情報ではなく、その取引によってどのような内容なのか異なる情報である。
マスタデータ
マスタデータは取引(オーダー)ごとに固有でない情報を指す。
具体的には、受注先の社名や住所、出荷先の社名や住所、商品名などが挙げられる。
受注先自体は取引によって異なるが、その受注先の社名や住所に関しては取引によって異なるわけではない、という切り分けである。
また、マスタデータにすることで情報の内容を統一することができる。例えば社名の書き方は人によって「株式会社」という場合と「(株)」という書き方に分かれるが、それをどちらかに統一する
マスタデータとして切り分けて管理するメリットは、①手間を減らす②ミスを減らす③集計などのデータ管理を適切に行う点が挙げられる。
※野菜のように時期によって価格が異なるケースもあるが、その場合はマスタデータにすべきかトランザクションデータにすべきか目的を踏まえた上で検討すべきである。
ヘッダと明細
主にトランザクションデータにまつわるトピックであり、取引の共通情報をヘッダデータとして切り出し、共通ではない情報を個別の明細データとして切り出す考え方に基づいている。
ヘッダ:取引に共有する情報を切り出したデータ(=ヘッダデータ)
オーダー | 受注先 | 住所 | 出荷先 |
20211214001 | A社 | 東京 | XXX工場 |
※オーダーがキー項目
明細:取引に共有しない情報を切り出したデータ(=アイテムデータ)
オーダー | 明細 | 商品 | 数量 | 単価 | 金額 |
20211214001 | 0001 | A | 10 | 200 | 2,000 |
20211214001 | 0002 | B | 20 | 300 | 3,000 |
※オーダーと明細がキー
1つの取引で扱う商品は1つと限らず、ヘッダのみでは複数の商品に対するオーダーがあった場合にカラムがどんどん増えていく形となってしまう。それらを上手く管理するために明細テーブルが登場する。
ヘッダと明細は親子関係のようなものであり、取引固有の1つしかない情報がヘッダ、取引固有でない情報を明細と呼ぶ。商品は取引に1つしか存在しないものではなく取引の中で複数回登場する可能性があるため、そのような定義付けがされている。
データを管理する際に、どのような視点で切り分けるべきか、どこが親子関係・主従関係になっているかというのを理解することでどう管理すべきかへの理解が深まる。
1つのテーブルで全て完結すれば良いというわけではなく、親テーブルに対し子テーブルのようなものが付属しているという考え方をしっかり身に付ける必要がある。
まとめ
今回は、業務フローにおいては業務に伴い反映されるデータの関係性について、またトランザクションデータ/マスタデータやヘッダ/明細においてはオーダーごとに共通か否か、というように1つ1つの項目ではなく大きな繋がりを見るシーンが多かった。必ずトランザクションデータにはこの項目、というような暗記型の理解ではなく、何故そういった切り分けをしているのかという点についての理解も深めた。
システムを開発するにおいて、共通事項や前後関係、依存関係といった関係性に着目できるかという部分はその人自身のキャリアに大きく影響を与えるだろう。
業務フロー1つ1つやテーブル1つ1つへの理解も大事ではあるが、それらの理解を通して何が見えるか、何を身に付けるかという話にも結び付け、これからも努力を続けたいと改めて思った。
コメント