あくまで個人的見解です。
■基幹業務の種類
事業会社における基幹業務としてはおおむね以下が挙げられる。
- 販売業務：顧客管理、受注残管理など
- 購買業務：仕入先管理、発注残管理など
- 製造業務：生産計画、進捗管理など
- 物流業務：在庫管理、輸配送管理など
- 経理業務：財務会計、管理会計など
- 人事業務：勤怠管理、労務管理など
このうち販売・購買・経理・人事の各業務については、
法改正や外貨対応など外部要因の影響を受けやすいため、
内製の体制を組まないと仮定するなら、
パッケージやクラウドサービスを利用した方が、
運用面でメリットがあるように思われる。
各業務について想定されるエンティティを挙げていく。
■販売業務の情報種
取引データ（トランザクションデータ）に着目すると以下の流れになる。
販売業務はエンティティが多くなるがそのほとんどはステータス移動のため、
受注明細や売り上げなど他業務接点以外はそれほど複雑でないようにも思われる。
販売目標
商品企画・マーケティングを経て当該品目の販売目標を立てる。
おおむね大日程（年次）で計画し、
中日程（月次）・小日程（日次）に案分したうえで微調整も行う。
製造部門の生産計画（大日程・中日程・小日程）にもゆるやかにリンクする。
【商談管理】
リード
見込み顧客のため、顧客情報や得意先情報を登録するまでには至らない情報。
展示会で名刺交換したりウェブ広告をきっかけに問い合わせを受けたり、
まだ具体性はあまりないが関心を抱いている状態。
提案
見込み顧客と接触した履歴。
具体性がないままでも提案した内容や見込み顧客との会話内容など記録して、
社内で共有できるようにする。
引合
顧客から具体的に見積依頼があった際に記録を残す。
品目・数量・希望単価など。
見積
引合いに対して見積を提出する。
再見積もりを行う場合もあるため、
引合IDを必須の外部キーとして複数保持できるようにしておく。
また注文に発展しないこともありうるため、
失注フラグなどで管理できるようもしておく。
【受注残管理】
注文
見積に対して注文が入るが、
一方でネットオーダーなど見積を経ない注文もあるため、
見積IDは任意の外部キーとして保持する。
受注
営業部の上長承認などで注文が確定した場合に、
注文後に確定した内部情報を含む受注情報として、
注文情報とは分けて創生しておく。
受注が確定したのち、
総引当（論理在庫上の引き当て）が掛かれば物流への出荷依頼情報に、
在庫がなければ製造部・購買部への入荷依頼情報へと引き継がれる。
引当
受注情報について任意の引き当てタイミングで何個引き当てられたか履歴管理する。
時刻バッチの引き当て処理などで複数回の処理で受注数を満たす場合もあるため、
受注IDを外部キーとして複数保持できるようにしておく。
出荷依頼
引当情報をもとに営業部門から物流部門に出荷を依頼する。
分納のため一部のみ出荷依頼をかける場合は引き当て残の管理も行う。
入荷依頼
論理在庫が足りず総引当ができなかった場合は、
購買部門・製造部門に倉庫への入荷依頼を行う。
品目の調達方法により購入計画・製造計画に派生する。
売上
受注情報が受注残管理・物流業務を経て出荷・納品が確認されると売上情報を創生する。
分納の場合もあるため受注IDは必須の外部キーとして複数保持できるようにしておく。
■購買業務の情報種
売り方が決まれば必然的に仕入のボリュームも想定できる。
営業部門・製造部門・物流部門からの依頼を受けて発注する。
購入計画
販目から設定された小日程生産計画、営業からの入荷依頼、物流からの補充依頼
の何れかから仕入れ商品について購入計画を創生する。
発注
上記の購入計画、後述する部品の製造指示や社外の加工指示を受けて、
実際に発注する際に品目・数量・単価などを記録しておく。
割戻金などがある場合はここで赤伝を差し込む。
仕入
任意の発注について、入場・入港した実績を記録する。
分納も考慮して、発注IDは外部キーにし複数管理できるようにしておく。
輸入の場合は船積み日、出航日、入港日などを記録し、
締め時点でレート換算できるようにしておく。
■製造業務の情報種
製造計画
販目から設定された小日程生産計画、営業からの入荷依頼、物流からの補充依頼
の何れかから製造する製品について製造計画を創生する。
製造指示
計画された製品について部品表における構成品を含め、
すべての品目について必要数や自至日を計算し、
対象の品目ごとに明細を追加する。
構成のうち複数回出現する部品は明細も親品番ごとに複数回発生する。
加工指示
製造指示された各品目について加工の内容・順番・数量・自至日を計算し、
加工内容ごとに明細を追加する。
作業実績
加工指示を受けて作業回ごとに実績を記録する。
作業日ごとに開始時間・終了時間・数量など記録しておくのが望ましい。
複数回に渡るケースのあるため、加工IDは外部キーにしておく。
仕掛出庫
ロケにある材料・部品や、
加工終了時の入出庫を徹底している場合はその入庫ロケから、
段取り開始時に出庫登録を行う。
仕掛入庫
加工終了時や発注品の検査完了時などにロケへの入庫登録を行う。
仕掛棚卸
上記の入出庫は移動履歴でありロストする可能性も否めないため、
任意のタイミングで実棚数を記録しておく。
論理在庫は棚卸日以降の入出庫履歴から計算する。
■物流業務の情報種
実際のモノの管理となるため物流業務もエンティティが多岐にわたる。
これは情報移送のタイミングで関連が複数対複数（n:n）になりやすいためでもある。
【入出庫管理】
出庫計画
営業部門からの出荷依頼を物流部門が確認し、
実在庫を確認できたなら出庫計画を追加（実引当）する。
出庫が可能であることを確認した状態。
出庫指示
主にピッキングリストの出力タイミングで、
確定済みの出庫計画を出庫指示にまとめる。
出庫計画に出庫指示済みをマークする。
実際のピッキングリストは棚順を考慮して出力する。
検品
ピッキングリストに従って出庫された際に、
在庫管理として品目ごとに数量が出庫登録されており、
その出庫実績ごとに検品結果を登録する。
荷揃
検品後に納品先別・運送会社別に納品物を整える。
出庫・検品・荷揃えでの品目の組み合わせは流動的な側面もあるため、
各種キーを外部キーとして引き継ぎトレーサビリティを保てるようにする。
出荷
実際に出荷もしくは運送会社に引き渡した際に実績を記録する。
荷揃えにも出荷済もしくは受領済をマークし売上計上できるようにする。
入庫依頼
購買部門・製造部門で入庫の準備ができ次第、入庫依頼を行う。
事前に入庫予定として購入計画・製造計画時から参照できるようにすることもある。
入庫計画
出庫時と同じく、入庫依頼を物流部門が確認できれば、入庫計画を立てる。
品目について、用途・ロケなどを決定しておく。
入庫指示
出庫時と同じく、任意の入庫計画から棚順に明細を選択し、棚入れ指示書を出力する。
可能なら担当者も指定しておく。
【在庫管理】
出庫
ピッキングリストに則って品目をロケから集めて回る。
対応済みのピッキングリストを読み込み該当する品目を全て出庫済みとするか、
ピッカーにデバイスを配布できるならリアルタイムに登録していくと、
作業実績とリンクすることも期待できる。
入庫
出庫と同じく棚入れ指示書に則って作業を行う。
出庫時と違いパレット単位で行うケースもあるため、
リフトやリーチの操作面近辺にデバイスを配置できればより効率的になる。
棚卸
出庫・入庫の実績は品目谷で残していくが、やはり一定期間で精査することも必要になる。
同タイミングで一気に行うと物流部員に多大な負荷がかかるため、
建屋・エリアごとに通期で循環棚卸とする方が現場負荷は抑えられるように思われる。
補充
安全在庫や発注点と呼ばれる在庫数を切ったタイミングで、
購買部門・製造部門に補充の依頼をかける。
製造部門で加工をしないような軽加工（包装など）の場合は包装の依頼となる。
包装出庫
包装材などの出庫情報を記録し、包装材自体の発注点管理も行う。
包装入庫
包装済みの品目を入庫し在庫数管理する。
包装出庫・包装入庫は部門間で移動するのでなく物流部門内で品目が移動するため、
営業部門・購買部門・製造部門からの入出庫とは別で管理するように想定している。
■経理業務の情報種
請求
顧客もしくは得意先単位に、
複数の売り上げをまとめて請求情報とする。
売上情報には請求IDを植え付けて請求済みとする。
入金
銀行からの入金情報を取り込む。
回収
取り込んだ入金情報と請求残を突合し、
未回収の請求情報を回収済みとする。
支払
仕入先単位に、
複数の仕入をまとめて支払情報とする。
仕入情報には支払IDを植え付けて支払処理済みとする。
出金
銀行からの出金情報を取り込む。
履行
取り込んだ出金情報と支払残を突合し、
未払いの仕入情報を履行済みとする。
標準原価
製品設計時に設定した標準的な製品原価。
実績原価
年間・月間の実績も考慮して、標準原価とほぼ同じ計算式で算出した原価。
販売計画にフィードバックするなど、情報は循環していく。
■人事業務の情報種
システムの利用設定として、
ある程度の規模の組織ならLDAPで管理されることが多いが、
システム内に取り込む場合は以下の構成になることが多い。
ユーザマスタ
ログインID・パスワードなどを管理する。
部署マスタ
親部署も設定するなどして組織内の部署を管理する。
職位マスタ
組織内の職位について管理する。
所属マスタ
どのユーザがどの部署でどの職位かを管理する。
主キーに適用日を持ち履歴を持つと管理が容易になると思われる。
職位認可マスタ
所属マスタに則って画面や機能について権限を設定する。
稼働日マスタ
日付ごとに稼働日をフラグ管理する。
部署によって稼働日が異なる場合は主キーに部署IDも追加する。