kintoneで在庫管理システムを作るときの要件定義・設計ポイント

devkin Meetup! Vol.8 の登壇資料です。

Transcript

1. devkin Meetup! Vol.8 kintoneで在庫管理システムを作るときの 要件定義・設計ポイント 松村稔@プロ牛乳石鹸 1
2. 自己紹介 松村 稔 岐阜県出身 上海でkintoneやってます。 2
3. 普段やってること @kai0707 3
4. kintoneでやってること オーダーメイドで業務改善のシステムを作っています。 販売管理 在庫管理 見積管理 案件管理 4
5. kintoneで在庫管理システムを作るときの 要件定義・設計ポイント 5
6. kintoneの標準機能だけでは、 ちゃんとした在庫管理は作れない というのが、一般の共通認識かなと思います。 6
7. ちゃんとした在庫管理ってなに？ ※ 商社・貿易会社等、生産を伴わない会社という前提 入庫と出庫により 在庫数量が計算される 入出庫以外で 在庫の増減が可能 （計画外の入出庫） 複数倉庫の 在庫管理が可能 必要に応じて ロット別の先入先出が可能 前月末時点の 在庫の把握が可能 総平均計算による 在庫評価の計算が可能 在庫過不足の 表現が可能 滞留在庫の 把握が可能 預託在庫の 管理が可能 7
8. ポイント１：“在庫”の用語定義 8
9. “在庫”って、どの在庫？ 用語 意味 在庫 全ての在庫のことを包括する表現。なんの在庫の事なのかは背景を共有 しないとわからない 理論在庫 システムに表示されている在庫数。理論上これくらいあるはず、という在庫 数 物理在庫 現実に存在する物理的な在庫。理論在庫と一致するとは限らない（その 差異を調べるのが棚卸） 倉庫別理論在庫 理論在庫をさらに倉庫別に振り分けたもの 使用可能在庫 実際に使用可能な在庫数。この定義は会社ごとに違う 9
10. 使用可能在庫の認識方法も把握しておく 例１）良品倉庫と不良品倉庫 理論在庫 100 ＝ 良品倉庫 90 ＋ 不良品倉庫 10 使用可能在庫 90 例２）引当済みがある 理論在庫 100 － 引当済み 30 営業から見た使用可能在庫 70 作ってもらう側も、作る側も、“在庫”とはなにかを共通認識に 10
11. ポイント２：在庫を一意に定めるキー 11
12. 在庫のキーをどう定義するか ロット管理しない場合 倉庫コード ＋ 品番 ＋ 品番 ロット管理する場合 倉庫コード ＋ 入荷ロット番号 • kintoneは複合キーは実現できないため、在庫キーの様な項目を設けてそこに連番をいれ てキーとして管理 • ここさえしっかり定義できていれば、入荷アプリ・出荷アプリ側の根本の仕組みはあまり大差 はない 12
13. キーを決める前に確認しておくこと • 複数倉庫で運用するか（将来的に預託在庫の管理も加味して） • ロット別の先入先出が必要か • 製品一つ一つにロット番号（シリアル番号）を振ってトレーサビリティを確 保する必要があるか • 棚卸差益発生時に計画外入庫で生まれる在庫について、どのようなロッ ト番号をふるか ロット番号をふるかどうかは、在庫アプリの設計にダイレクトに関係してきます 13
14. 預託在庫も倉庫別在庫の一環で 倉庫移動 自社倉庫 月に１回、実数を出庫 預託倉庫 売上 （お客様の倉庫） 場所はお客様の倉庫 所有権はまだ自社 ここではじめて 所有権がお客様に 逆に、預かり品の在庫管理は？ → 「資産」かどうかで判断。「資産外」はシステムでは管理しません。 14
15. ポイント３：在庫増減のロジック 15
16. 在庫の２つの計算方式 本来は方式１で組みたい けど、kintoneではSQL文で複数アプリ の情報を差し引くというような計算ができ ない → やむを得ず方式２（但し方式１も 併用になる可能性あり） 16
17. 在庫引き落としロジック（出荷の例） 1 出荷画面で品目選択時、在庫アプリの在庫数を表示 2 保存直前に在庫を再取得（リビジョン番号を取得） 3 取得した在庫数と今回の出荷数を比較して、在庫が負数にならないかをチ ェック 4 問題なければ在庫を更新。在庫レコードのリビジョンが異なっていた場合は エラー 17
18. 割り切りも大事 よくある疑問 入力中に画面に表示された在庫数と、最後に引き落とすときの在庫数が 変わっていたらどうするのか 前提 出荷画面で在庫数を見ながら、何をいくつ出荷するかの意思決定をしてい る使用者は少ない → 保存時に負数にさえならなければよし （無論必要なときはきちんと組み込みます） 18
19. 計画外入出庫も忘れずに 計画外入庫 計画外出庫 • 棚卸差益（理論値よりも実数の方が多かった） • 研究開発等に払い出したものの戻入 • 棚卸差損（理論値よりも実数の方が少なかっ た） • 破損やその他事情による廃棄処理 • 研究開発用の払い出し • サンプル品としての払い出し 社内ルールとして決めておく： 計画外入庫で生成される在庫のロット番号規則、在庫評価 誰もが好き勝手に在庫を増減させられないように、適切なアクセス権限（操作記録は監査 ログで） 19
20. ポイント４：月次在庫と在庫評価 20
21. 在庫アプリと月次在庫アプリ 在庫アプリ 月次在庫アプリ 在庫を一意に定めるユニークなキー ユニークなキー 対象月 倉庫コード 倉庫コード 品番 品番 前月残数量 前月残金額 在庫数 当月入庫数量 当月入庫金額 最終出荷日 当月出庫数量 当月出庫金額 最終入荷日 当月残数量 当月残金額 最終出荷日・最終入荷日は 滞留在庫把握で使いそう 総平均で算出された単価 21
22. 在庫評価金額の計算方法（月別総平均法） 前月残在庫金額 ＋ 当月入荷金額 ＝ 前月残在庫数量 ＋ 在庫評価単価 当月入荷数量 • 月次でデータを持つ → 破壊的更新にしない（プログラム異常で大切な残情報が 消えてしまうので） • 計算された在庫評価単価を、該当月の出荷アプリの履歴に書き戻す → 出荷毎 の粗利が算出可能 22
23. 評価単価は計算式？プログラム？ kintoneの計算式で計算 総平均計算をかけるときにプログラムで計 算して代入 メリット メリット 該当レコード更新時にリアルタイムで自動 計算される 端数等の特殊な処理が発生する場合にも 柔軟に対応できる → 良し悪し 23
24. その他いろいろ 24
25. 在庫過不足の表現 今の在庫数がわかるだけでは 、在庫管理としては物足りな い ざっくりでも今の在庫の過不足 がわかるとよい kintoneの標準機能では複数アプリの情報を集計することができないため、独自カスタマイズ で都度集計するかプラグインつかう。 25
26. 過不足は専用画面で 受注画面 確定した注文情報を 入力することに特化 実際の仕事では「内示」や「安全在庫」等 の各種要素も関係してくる 商品過不足確認画面 1. 商品コード 2. 商品名 3. 在庫数 4. 受注残数 5. 在庫過不足（3引く4） 6. 発注残数 7. 将来過不足（5足す6） • 商品マスタにリアルタイムで集計数字を更新してもよいが、複数担当が同時に同じ商品 に対して処理を行うこともあり、制御がめんどくさい 26
27. 滞留在庫の把握 「最終入荷後に〇ヶ月出荷されていない在庫」 • 商品毎に最終入荷日と最終出荷日を項目として設けて、入荷時・出荷 時に値を代入 • kintoneの計算式はレコードの編集イベントが発生しないと再計算されな いので、最終日付だけを保持して検索条件で抽出 27
28. 滞留在庫を把握したら 顧客起因 顧客への買取交渉 内部起因 再発防止策の立案 滞留在庫が発生した原因を業務として追いかけられることが大切 • 販売管理システムだけの話ではなく、顧客からの内示の保管や、商品発注時の 根拠の保管等、多岐に渡る • システムのデータと業務上のデータを上手く組み合わせて、発生原因が追いかけ られる状態を作っておく 28
29. トレーサビリティ、どこまで？ 「どの製品が、いつ、どのお客様に販売されたのか」 1 製品一つ一つにロット番号（シリアル番 号）を振る必要があるか 在庫アプリの設計にダイレクトに関係。入荷・在庫 ・出荷それぞれにロット番号の項目を持たせる 2 お客様から問い合わせがあった時に、生 産までさかのぼれるか 製造部門・品質管理部門も関係。kintoneは 全文検索機能が充実 3 トレーサビリティを確保するための工数 出荷場（出荷倉庫）に作業負荷。バーコード・ QRコードによる読込も検討 29
30. ありがとうございました！ 30