2026年7月6日
卸売業の受発注管理システムを自社専用に開発した事例｜電話・FAX・Excel転記からの脱却
卸売業の受発注業務は、電話・FAX・Excelが混在したままでも、自社専用のシステム開発で一元管理へ移行できます。 本記事でご紹介するのは、私たち株式会社猛烈エンジニアリングが手がけた開発プロジェクトです。卸売業の企業向けに「受発注管理システム」を自社専用で開発しました。
この記事でわかること
- 電話・FAX・Excel転記が混在した受発注業務の、何が問題だったか
- 自社専用の受発注管理システムで、実際に何を作ったか
- 既製SaaSではなく個別開発を選んだ判断基準
- 業務を止めずに移行する「段階導入」の進め方
プロジェクトの背景｜電話・FAX・Excelに分かれた受発注
このプロジェクトの出発点は、受注経路が電話・FAX・メールに分かれ、同じ情報を何度も入力する構造そのものにありました。
ご相談いただいたのは、複数の得意先を抱える卸売業の企業です。愛媛県を含む四国の卸売業では、取引先に今もFAX文化が根強く残っています。デジタル化を取引先へ一方的に求められない事情が、社内の負担を増やしていました。
初回のヒアリングで事務所に伺ったとき、私が最初に目にしたのは、壁際に並んだFAX受注票のクリップボードでした。担当者ごとに「自分の得意先の紙」を管理する光景。この時点で、課題は道具ではなく情報の置き場所の分散だと感じました。
現場の課題は、次の3点に整理できます。
- 受注経路の分散: 電話・FAX・メールで届く注文を、それぞれ別の手順で処理していた
- 担当者依存: 得意先ごとの価格や納品ルールが担当者の頭の中にあり、不在時に対応が滞る
- 二重入力: FAXからExcelへ、Excelから販売管理へと転記するたびに、ミスの入り込む余地があった
属人化が生まれる構造的な原因と一般的な解消手順は、別記事「受発注のシステム化で属人化を解消する方法」で解説しています。本記事は事例編として、プロジェクトで実際に何を作ったかに絞って進めます。
開発したもの｜受注一元管理・在庫連携・権限とログ
私たちが開発したのは多機能なパッケージではなく、**「受注の入口を1つにする」**ことに絞った自社専用システムです。
開発した機能と、それぞれの設計の狙いを表にまとめます。
| 機能 | 内容 | 設計の狙い |
|---|---|---|
| 受注一元管理 | 電話・FAX・メール経由の注文を1つの受注台帳に登録 | 入力の一回化。転記ミスの発生源を断つ |
| 得意先マスタ | 得意先ごとの価格・納品条件・締め日をデータ化 | 頭の中の情報を全員が見られる状態にする |
| 在庫・仕入連携 | 受注確定と同時に在庫引当と発注候補を表示 | 在庫確認の電話往復をなくす |
| 権限とログ | 役割ごとの操作権限と変更履歴の記録 | 「誰がいつ変えたか」を後から追えるようにする |
FAXの受信をやめてもらうのではなく、届いた注文を画面のフォームに沿って登録する運用にしました。取引先には従来どおりFAXを使ってもらいながら、社内では紙が届いた瞬間にデータ化する設計です。
中心に据えたのは、二重入力の根絶です。受注台帳に一度入力すれば、納品書・請求データ・在庫引当まで同じデータが流れます。入力は一回、参照は全員。これが設計の合言葉でした。
権限とログは後回しにされがちな機能です。しかし卸売業では、値引きや数量変更が日常的に起きます。変更履歴が残る仕組みこそ現場の安心につながると考え、初期段階から組み込みました。
受発注まわりの整理を検討中の方は、現状のフローを箇条書きにした段階でも構いません。お気軽にご相談ください。
段階導入の進め方｜一度に全部を作らない
このプロジェクトでは全機能の一括開発を避け、3段階に分けて小さく導入する進め方を採りました。
段階の区切りは次のとおりです。
- 第1段階: 受注の一元管理。受注台帳と得意先マスタだけを先に作り、既存のExcel運用と並走させる
- 第2段階: 在庫・仕入との連携。受注データが安定して溜まってから、在庫引当と発注候補を追加する
- 第3段階: 権限・ログの本格運用と帳票の自動化
第1段階の稼働直後、現場の方が「FAXを見ながら電話で在庫を聞く回数が減った」と話していたのが印象的でした。数値での効果測定はこれからですが、業務の流れが変わる手応えは早い段階で現場に生まれています。
段階導入には明確な理由があります。卸売業の受発注は1日も止められない業務だからです。一括切り替えに失敗すれば、出荷が止まります。小さく入れて、慣れてから次へ。この順番が現場の負担を最小にします。
一般に、二重入力を排した受発注システムでは、転記ミスの削減と確認作業の短縮が見込まれます。ただし効果の大きさは業務量や取引先の構成で変わります。だからこそ私たちは、導入前に「何をどう測るか」を決めてから開発に入るようにしています。
既製SaaSとの違い｜自社専用開発を選んだ判断基準
既製SaaSと個別開発の分かれ目は、自社の商習慣をシステムに合わせられるかという一点にあります。
既製の受発注SaaSは初期費用を抑えられ、導入も速い選択肢です。一方このプロジェクトでは、得意先ごとの価格体系や納品ルールが複雑で、既製品の設定範囲に収まりませんでした。業務をシステムに合わせ直すコストのほうが高くつくという判断です。
| 観点 | 既製SaaS | 自社専用開発 |
|---|---|---|
| 初期費用 | 低い | 相対的に高い |
| 月額費用 | 利用し続ける限り発生 | 保守費のみ。システムは自社の資産 |
| 商習慣への適合 | 設定できる範囲まで | 業務に合わせて設計できる |
| 機能追加 | 提供元の開発を待つ | 必要な分だけ順次追加できる |
どちらが正解かは会社ごとに異なります。私たちも、既製SaaSで十分と判断したご相談には、開発を勧めずにその旨をお伝えしてきました。迷っている段階でのご相談こそ歓迎です。
この事例から持ち帰れること｜小さな一歩の設計
卸売業の受発注改善は、「受注の入口を1つにする」という小さな一歩から始められます。
全業務の一斉システム化は必要ありません。まず受注台帳の一元化だけを作り、効果を確かめてから次へ進む。この事例の進め方は、従業員10〜100名規模の卸売・小売・製造業であれば、そのまま応用できる型だと考えています。
私たちは愛媛県大洲市を拠点に、システム開発からAI導入、補助金の活用までを一気通貫で支援しています。従業員10名規模の会社からのご依頼実績もあり、「うちの規模で頼めるのか」という心配は不要です。まずは現状の受発注フローをお聞かせください。
執筆: 株式会社猛烈エンジニアリング（代表 藤井達也／愛媛県大洲市大洲98-1）。愛媛のシステム開発会社として、中小企業の業務システム開発・AI導入・DX支援を行っています。
