「発注依頼をExcelで管理している」
「承認状況がメールやチャットに散らばっている」
「誰が何を発注したのか分からない」
「納品予定日を毎回担当者へ確認している」
こうした問題が増えてきた場合、発注管理システムを作ることで業務を整理できる可能性があります。
発注管理システムを作る際に重要なのは、いきなり画面や機能を考えることではありません。
まず、
現状の発注業務
↓
困っていること
↓
システム化したい範囲
↓
必要な機能
↓
画面・データ・権限
↓
開発
という順番で整理することが重要です。
特に発注管理では、
依頼 → 承認 → 発注 → 納品待ち → 納品確認
という一連の流れをシステム上でつなげることがポイントになります。
この記事では、Excelやメールによる発注管理からWebシステムへ移行するケースを想定し、発注管理システムの作り方を具体的に解説します。
発注管理システムとは
発注管理システムとは、商品・資材・備品・外注業務などの発注に関する情報を一元管理するシステムです。
例えば、次のような業務を管理できます。
- 発注依頼
- 上司による承認
- 仕入先の選択
- 発注書の作成
- 発注処理
- 納期管理
- 納品確認
- 発注履歴の検索
- 発注金額の集計
企業によっては「購買管理システム」と呼ばれることもあります。
ただし、購買管理では見積依頼、仕入先評価、契約、検収、支払いなどまで含めるケースがあるため、発注管理より対象範囲が広い場合があります。
Excelによる発注管理で起こりやすい問題
小規模なうちは、ExcelやGoogleスプレッドシートでも十分に発注を管理できます。
しかし、発注件数や担当者が増えると問題が出てきます。
誰が何を発注したのか分からない
例えば部署ごとにExcelファイルを管理していると、
- 営業部発注一覧.xlsx
- 総務部発注一覧.xlsx
- 製造部発注一覧.xlsx
のように情報が分散します。
全社でいくら発注しているのか確認するだけでも、複数ファイルを集計しなければなりません。
承認状況が分からない
発注前に上司の承認が必要な会社では、
「メールを送ったが返信がない」
「チャットでは承認されたがExcelには反映されていない」
といった問題も発生します。
申請と承認をシステム化すれば、
- 申請中
- 承認済み
- 差し戻し
- 却下
などのステータスを確認できます。
発注漏れが発生する
例えば、
担当者が発注依頼を作成
↓
上司へメール
↓
承認
↓
購買担当者へ連絡
↓
仕入先へ発注
という流れの場合、途中の連絡が漏れる可能性があります。
発注管理システムでは、ステータスを使って処理状況を管理できます。
納期確認に時間がかかる
「この商品はいつ届くのか」
という問い合わせのたびに、
- メールを検索
- 発注書を確認
- 担当者へ連絡
- 仕入先へ確認
しているケースもあります。
発注情報に納品予定日を持たせれば、システム上ですぐに確認できます。
発注管理システムを作る基本的な流れ
発注管理システムは、次の順番で作ると整理しやすくなります。
1. 現在の発注業務を整理する
最初にAs-Is（現在の業務）を整理します。
例えば現在、
担当者が商品を選ぶ
↓
Excelへ入力
↓
上司へメールで承認依頼
↓
上司が返信
↓
購買担当者へExcelを送る
↓
購買担当者が仕入先へメール
↓
商品到着
↓
Excelへ「納品済」と記入
という流れになっているとします。
まずはこの流れを書き出します。
システム開発では、この現状把握が非常に重要です。
2. 現在困っていることを整理する
次に、現在の課題を整理します。
例えば、
- Excelへの入力漏れがある
- 承認メールを探すのが大変
- 発注済みか判断できない
- 納期が分からない
- 同じ商品を重複発注する
- 月ごとの発注額集計に時間がかかる
- 発注履歴を探しにくい
といった問題です。
3. システム導入後の業務を考える
次にTo-Be（システム導入後の理想的な業務）を整理します。
例えば、
担当者がシステムから発注依頼
↓
上司へ自動通知
↓
上司がシステム上で承認
↓
購買担当者に通知
↓
購買担当者が発注処理
↓
納品予定日を登録
↓
商品到着後に納品完了
という流れです。
このようにすると、メールやExcelを行き来する必要が少なくなります。
発注管理システムに必要な基本機能
必要な機能は企業によって異なりますが、一般的な発注管理システムでは次のような機能が候補になります。
1. 発注依頼機能
担当者が発注したい内容を登録する機能です。
例えば次の項目を入力します。
- 商品名
- 商品コード
- 数量
- 希望納期
- 発注理由
- 仕入先
- 単価
- 金額
- 備考
商品マスタがある場合は、商品を選択すると単価や仕入先を自動表示させることもできます。
2. 承認機能
発注前に上司や管理者の承認が必要な場合は、承認機能を作ります。
例えば、
申請
↓
課長承認
↓
部長承認
↓
発注可能
というワークフローです。
ただし、最初から複雑な承認フローを作る必要はありません。
例えば、
- 10万円未満：課長承認
- 10万円以上：部長承認
のようなルールがある場合だけ、条件分岐を追加します。
3. 発注ステータス管理
発注業務では、現在どこまで進んでいるのか分かることが重要です。
例えば次のステータスを使用します。
- 下書き
- 申請中
- 承認済み
- 発注済み
- 納品待ち
- 一部納品
- 納品完了
- キャンセル
一覧画面を見るだけで進捗を確認できる状態を目指します。
4. 発注書作成機能
承認された発注内容から発注書を作成できると、転記作業を減らせます。
例えば、
- 発注番号
- 発注日
- 仕入先
- 商品
- 数量
- 単価
- 合計金額
- 納品先
- 希望納期
などを自動でPDFへ出力します。
システム内の情報から発注書を作成することで、発注内容と発注書の不一致も防ぎやすくなります。
5. 仕入先管理
発注先が複数ある場合は、仕入先マスタを作ります。
例えば、
- 仕入先コード
- 会社名
- 担当者
- 電話番号
- メールアドレス
- 支払条件
- 備考
などを管理します。
発注時に仕入先を選択できるようにすると入力負担を軽減できます。
6. 商品・品目マスタ
同じ商品を繰り返し発注する場合は、商品マスタを作ると便利です。
例えば、
- 商品コード
- 商品名
- カテゴリ
- 標準単価
- 発注単位
- 標準仕入先
- リードタイム
などを登録します。
発注依頼時には商品を選択するだけで必要情報を呼び出せます。
7. 納品管理
発注しただけでは業務は完了しません。
実際に商品が届いたか管理する必要があります。
例えば、
- 発注数量
- 納品数量
- 納品日
- 未納数量
を管理します。
100個発注して50個だけ先に届いた場合など、一部納品にも対応できる設計が必要になることがあります。
8. 検索・絞り込み機能
発注件数が増えてくると検索機能が重要になります。
例えば、
- 発注番号
- 商品名
- 仕入先
- 担当者
- 部署
- 発注日
- 納品予定日
- ステータス
などで検索できるようにします。
「今月未納の発注だけ表示する」
といった検索ができると実務で使いやすくなります。
9. CSV・Excel出力
管理者が集計や分析を行う場合は、CSVやExcelへ出力できる機能も有効です。
例えば、
- 月別発注額
- 部署別発注額
- 仕入先別発注額
- 商品別発注数量
などを集計できます。
すべての集計機能をシステム上に作るのではなく、必要に応じてExcelへ出力して分析する方法もあります。
10. 通知機能
担当者がシステムを毎日確認するとは限りません。
そのため、
- 発注申請された
- 承認された
- 差し戻された
- 納期が近づいた
- 納期を過ぎた
といったタイミングで通知を送ると便利です。
通知先としては、
- メール
- Slack
- Microsoft Teams
などが考えられます。
発注管理システムの画面構成例
小規模な発注管理システムであれば、例えば次のような画面構成にできます。
ダッシュボード
ログイン後に、
- 承認待ち件数
- 発注待ち件数
- 納品待ち件数
- 納期超過件数
- 今月の発注金額
などを表示します。
発注一覧
すべての発注情報を一覧表示します。
主な表示項目は、
- 発注番号
- 発注日
- 申請者
- 仕入先
- 金額
- 納品予定日
- ステータス
などです。
発注登録
新しい発注依頼を登録する画面です。
商品や仕入先を選択し、数量や希望納期などを入力します。
発注詳細
1件の発注について、
- 発注内容
- 承認状況
- 発注状況
- 納品状況
- コメント
- 更新履歴
などを確認します。
承認画面
承認者が、
- 承認
- 差し戻し
- 却下
を行います。
差し戻す場合はコメントを入力できるようにすると、申請者が修正内容を理解しやすくなります。
商品マスタ
商品情報を登録・編集します。
仕入先マスタ
仕入先情報を管理します。
ユーザー管理
利用者や権限を設定します。
発注管理システムのデータ設計例
Webシステムとして開発する場合、データベースには複数のテーブルを用意します。
例えば、
- ユーザー
- 部署
- 仕入先
- 商品
- 発注
- 発注明細
- 承認履歴
- 納品履歴
などです。
発注と発注明細は分ける
例えば1回の発注で、
- コピー用紙 10箱
- ボールペン 100本
- ファイル 50冊
をまとめて購入するケースがあります。
この場合、
「発注」
と、
「発注した商品」
を別々に管理します。
発注には、
- 発注番号
- 仕入先
- 発注日
- 担当者
- 合計金額
- ステータス
を持たせます。
発注明細には、
- 商品
- 数量
- 単価
- 金額
を持たせます。
このようなデータ構造にすると、1件の発注に複数商品を登録できます。
発注管理と在庫管理を連携する方法
発注管理システムを作るときによく出てくるのが在庫管理との連携です。
例えば、
在庫数が減る
↓
発注点を下回る
↓
発注候補を表示
↓
担当者が確認
↓
発注申請
↓
承認
↓
仕入先へ発注
↓
商品入荷
↓
在庫数を増やす
という仕組みです。
例えば商品Aについて、
現在庫：20個
発注点：30個
発注数量：100個
と設定しておけば、在庫が30個を下回った時点で発注候補として表示できます。
ただし、最初から完全自動発注にする必要はありません。
まずは「発注候補を表示して、人が確認して発注する」という半自動化から始める方法もあります。
発注管理システムを自作するときの技術構成
Webシステムとして開発する場合、さまざまな技術構成が考えられます。
例えば、
フロントエンド：React / Next.js
バックエンド：Next.js / Python / Java
データベース：PostgreSQL / MySQL
インフラ：AWS / Vercelなど
といった構成です。
ただし、技術選定より重要なのは、
- 利用人数
- 発注件数
- セキュリティ
- 外部システム連携
- 将来の機能追加
- 運用方法
を整理することです。
小規模な社内システムであれば、大規模なインフラ構成は必要ない場合もあります。
発注管理システムはSaaSとスクラッチ開発のどちらがよい？
発注管理システムは、自社開発だけが選択肢ではありません。
既存のSaaSやパッケージ製品を利用する方法もあります。
SaaSが向いているケース
例えば、
- 発注業務が一般的
- 独自ルールが少ない
- すぐ導入したい
- 初期費用を抑えたい
という場合は、既存サービスを利用した方が合理的な可能性があります。
独自開発が向いているケース
一方、
- 独自の承認ルールがある
- 在庫管理と連携したい
- 基幹システムと連携したい
- 自社独自の発注方法がある
- 既存SaaSでは入力項目が合わない
- 発注後の業務まで一元管理したい
といった場合は、スクラッチ開発を検討する価値があります。
重要なのは、最初から「開発する」と決めるのではなく、既存サービスで実現できるかも含めて比較することです。
発注管理システムを作るときの注意点
最初から機能を増やしすぎない
発注管理を検討すると、
- 見積管理
- 契約管理
- 在庫管理
- 請求管理
- 支払管理
- 予算管理
- 仕入先評価
など、関連機能が次々に出てきます。
すべてを最初から作ると開発規模が大きくなります。
まずは、
依頼 → 承認 → 発注 → 納品確認
という中心業務からシステム化する方法が現実的です。
例外処理を整理しておく
通常の流れだけでなく、例外も確認しておきます。
例えば、
- 発注後に数量変更
- 発注キャンセル
- 一部納品
- 納品遅延
- 返品
- 発注先変更
などです。
実際の業務では例外処理が多いため、要件定義の段階で確認することが重要です。
権限を整理する
発注情報には価格や仕入先情報が含まれるため、誰でもすべて閲覧できる設計が適切とは限りません。
例えば、
一般社員：
自分が申請した発注のみ閲覧
部署管理者：
所属部署の発注を閲覧・承認
購買担当者：
全社の発注情報を閲覧
システム管理者：
マスタ・ユーザー管理
といった権限設計が考えられます。
操作履歴を残す
発注は金銭に関係するため、
- 誰が
- いつ
- 何を変更したか
を確認できるようにすると管理しやすくなります。
特に、
- 承認
- 金額変更
- 発注取消
- 納品処理
などは履歴を残すことを検討しましょう。
【コピペ用】発注管理システムの要件整理チェックリスト
発注管理システムを作る前に、次の内容を整理しておくと要件定義が進めやすくなります。
現在の業務
- 現在は何を使って発注管理しているか
- 誰が発注依頼をするか
- 誰が承認するか
- 誰が仕入先へ発注するか
- 納品確認は誰が行うか
- 月間の発注件数は何件か
- 仕入先は何社あるか
発注内容
- 何を発注するか
- 発注単位は何か
- 価格は固定か
- 仕入先は固定か
- 1回の発注で複数商品を注文するか
承認
- 承認は必要か
- 承認者は誰か
- 金額によって承認者が変わるか
- 複数段階の承認が必要か
- 差し戻しはあるか
納品
- 納品予定日を管理するか
- 分納はあるか
- 検品は必要か
- 返品はあるか
システム連携
- 在庫管理と連携するか
- 会計システムと連携するか
- 基幹システムと連携するか
- CSV出力は必要か
- 発注書PDFは必要か
この段階で完璧に決める必要はありません。
分からない項目がある場合は、実際の業務を確認しながら整理していきます。
発注管理システムに関するよくある質問
Excelでも発注管理できますか？
発注件数が少なく、利用者も限定されている場合はExcelでも管理できます。
ただし、
- 複数人で更新する
- 承認が必要
- 発注件数が多い
- 納期管理が必要
- 履歴を残したい
といった場合はWebシステムの方が管理しやすくなる可能性があります。
発注書を自動で作成できますか？
可能です。
発注情報を登録した際に、そのデータからPDF形式の発注書を作成する仕組みを構築できます。
担当者がExcelへ再入力して発注書を作る必要がなくなります。
発注メールも自動送信できますか？
可能です。
承認済みになった発注について、
- 仕入先
- 件名
- 発注内容
- 発注書PDF
などを自動生成し、メール送信する仕組みも考えられます。
ただし、最初は人が内容を確認してから送信する方式にすると誤発注を防ぎやすくなります。
在庫が減ったら自動で発注できますか？
技術的には可能です。
ただし、在庫数だけで自動発注すると、
- 季節変動
- 大口案件
- 仕入価格
- 仕入先の変更
などを考慮できないケースがあります。
そのため、最初は発注候補を自動表示し、担当者が確認する仕組みから始める方法もあります。
スマートフォンから利用できますか？
Webシステムとして作れば、スマートフォンやタブレットから利用できるように設計できます。
倉庫や現場で納品確認を行う場合は、スマートフォン対応が有効です。
要件が決まっていなくても開発相談できますか？
可能です。
「Excelで発注を管理しているが限界を感じている」
という段階でも、現在の業務を確認することで必要な機能を整理できます。
システムの機能を先に考えるより、現在どのように発注しているのかを整理するところから始めることが重要です。
hiro-dev-labでは発注業務の整理からシステム開発まで相談できます
発注管理システムを作る場合、最初から詳細な仕様書を準備する必要はありません。
hiro-dev-labでは、
- 現在の発注業務のヒアリング
- Excelや既存システムの確認
- 業務フロー整理
- 課題整理
- 要求整理
- 必要機能の整理
- 画面一覧の作成
- 権限設計
- データ設計
- 発注管理Webシステムの開発
- 在庫管理との連携
- 発注書・帳票の自動作成
- メールなどの業務自動化
といった形で、システムを作る前の段階から整理できます。
例えば現在、
Excelへ発注内容を入力
↓
上司へメールで承認依頼
↓
購買担当者へ転送
↓
発注書を手作業で作成
↓
仕入先へ送信
↓
納品状況をExcelで更新
となっているのであれば、
発注依頼
↓
承認
↓
発注書作成
↓
発注
↓
納品管理
までを1つのシステムにつなげられる可能性があります。
一方で、既存のSaaSで十分に対応できる業務であれば、必ずしもスクラッチ開発する必要はありません。
まず現在の業務と課題を整理し、どこまでシステム化するのが適切なのかを判断することが、使いやすい発注管理システムを作るための第一歩です。