受注管理のエクセルが客先ごとにバラバラなとき｜受注・在庫・出荷を一本化する設計の考え方

受注・在庫・出荷の一本化とは、客先から届いた受注、原料や製品の在庫の増減、出荷、そして請求までを、同じ取引先・品目・ロットのデータでつなぎ、Excelへの転記なしで追える状態にすることです。

受注は客先ごとに書式の違うExcel（エクセル）で届き、受注管理もそのExcelで回し、在庫は各担当がExcelで別に管理し、運賃と保管料はExcelで計算して請求の画面に手で打ち込む。この記事では、基幹システムの刷新を検討している受託製造業の要件整理で確認した、こうした状況をもとに、受注・在庫・出荷を一本につなぐための設計の考え方を整理します。案件は提案と検討の段階です。導入の効果ではなく、調べて分かったことと設計の考え方として読んでください。

どんな状態から始まったのか？

対象は、客先から原料を預かり、加工・包装して、客先の指示どおりに出荷する中小の受託製造業です。製品は自社のものではなく、客先からの預かり品です。

業務の流れは、取引先の登録から始まり、受注、原料・資材の入庫、在庫、生産、出荷、請求と進みます。ところが、長年使ってきた基幹システムで実際に動いていたのは、生産したあとの包装・出荷と請求のまわりだけでした。ほかの区間は、次のようにばらばらでした。

区間	実際の管理	困っていること
受注	客先から届くExcel。書式は客先ごと	月・ケース数・kgの並び方がまちまちで、入力の前に人が選り分けて書き写している
原料・資材の入庫〜在庫	各担当者のExcel	システムにも機能はあるが、うまくいかず使われなくなった
運賃・保管料	客先ごとの運賃表と保管料を別のExcelで管理	出荷のたびに表を見て計算し、請求の画面へ手で入力している
月報・請求書	システムの帳票ではなくExcelで作り直し	客先ごとの受払月報（出荷の履歴と残高の報告）を毎月手で集計している

加えて、現行システムの保守の終了が近づいていました。刷新は避けられない一方で、今と同じ範囲を作り直すだけでは、費用に見合う効果が見えにくい状況でした。そこで、今Excelで回している区間も含めて、どこまでつなげるかを整理するところから始めました。

システムの在庫が合わず、在庫機能が使われなくなるのはなぜか？

ここが、一本化の設計で最も大事な発見でした。在庫の機能そのものはあったのに、現場が使うのをやめていたのです。理由は2つでした。

理由1：名目の数量と実際の数量の差を調整できない

原料や資材の入庫では、伝票や表示の数量（名目の数量）と、実際に量った数量がぴったり一致しないことがあります。ところが現行システムでは、この差をプラス・マイナスの両方向で調整する仕組みがありませんでした。システムの在庫と現物が合わない状態が続けば、現場はシステムの数字を信用しなくなります。

理由2：過去の入力誤りを直しても、在庫に反映されない

もう一つは、過去の入力を直せないことでした。現行システムは、在庫を月ごとの残高として持ち、それを上書きしていく方式でした。過去の伝票の誤りに気づいて書き直しても、すでに締めた残高には反映されず、誤ったデータが残り続けます。実際に、ロット別の在庫にマイナスの値が残っている画面も確認できました。

この2つから分かるのは、「入力が面倒だから使われない」のではなく、「間違いを正しく直せないから使われない」ということです。一本化の設計では、新しい機能を足す前に、数字を直せる仕組みを先に用意する必要があります。

受注管理のエクセルは、どう受け止めればいいのか？

書式はそろえてもらわず、受け取ってから寄せる

客先に書式の統一をお願いする方法もありますが、預かり品を扱う受託製造業では、客先の数だけ書式があるのが普通です。統一を前提にすると、一本化はいつまでも始まりません。そこで、客先の書式はそのまま受け取り、社内で共通の受注データの形に寄せる設計にします。

共通の形として持つのは、次のような項目です。

• 取引先（荷主）と、請求先・届け先
• 品目
• 月ごとの数量（この受注は契約で月別の数量が決まり、その都度出荷する形でした）
• 単位（kg・袋・ケース）
• 納期
• ロットの指定があるか

単位の換算は、品目のマスタに「1ケースは何袋、1袋は何kg」という形で持たせておきます。客先によって数量の書き方が違っても、同じ品目なら同じ数量として比べられるようになります。

AIの読み取りは「下書きまで」にする

客先ごとに違う書式の受注書をAIで読み取り、下書きとして取り込む仕組みも検討の対象になりました。ただし、ここには一つ決めごとを置きました。AIが読み取った内容は下書きとし、人が確かめてから登録することです。

書式が客先ごとに違う以上、読み取りの精度は書式のパターンごとに確かめながら上げていくしかありません。誤った数量の受注がそのまま登録されると、在庫の引き当てや納期の判断まで狂います。そのため、最初の段階では受注の手入力と納期の管理を標準にし、AIの読み取りは後から足せる追加の機能として位置づけました。受注が登録されていれば、納期が近づいた・過ぎたという通知を自動で出すこともできます。

在庫を正しく保つための、データの持ち方

一本化の中心は在庫です。ここでは、現場がシステムを信用できる状態にするための持ち方を整理しました。

1. 在庫は「残高」ではなく「動き」で記録する

入庫・出庫・振替・調整・廃棄といった一つひとつの動きを記録として積み上げ、残高はそこから計算する方式にします。過去の伝票を訂正したら、その日以降の残高を計算し直し、変更前と変更後の内容を履歴として残します。これで、「過去を直しても反映されない」問題を構造からなくせます。

2. 調整には理由を付ける

名目と実量の差や、棚卸しで見つかった差は、「調整」の動きとして、日付・ロット・プラスマイナスの量・理由の区分を付けて登録できるようにします。数字を直接書き換えるのではなく、なぜ直したのかが残る形にしておくと、あとから在庫のずれを追いかけるときの手がかりになります。

3. ロットと有効期限を、最初から項目として持つ

この案件では、加工途中の品（大袋に入った状態）はロットと袋ごとの番号で管理し、有効期限はありません。包装して製品になった段階で、ロットと有効期限をセットで持ちます。生産で大袋を投入するときは、袋の番号の範囲を指定すれば1袋ずつに展開され、最後の1袋だけ端数のkgを直せる、という入力の形を要件にしました。

出荷では、客先が指定したロットを選んで出します。実は、最初に作った試作の画面では「有効期限の近いロットから自動で選ぶ」動きを入れていました。しかし、要件を見直すと「客先が指定したロットを出す」が正しく、自動で選ぶ仕様は客先の指示と食い違います。試作の画面に入れた仮の仕様は、要件の根拠と照らし合わせて外しました。

4. 預かり在庫の「持ち主」をデータで持つ

受託製造業ならではの論点が、在庫の持ち主です。同じ製品でも、どの客先からの預かり品かで在庫を分ける必要があります。さらに、ある客先の預かり在庫を別の客先向けに振り替える処理があり、現行システムでは出庫と入庫の2枚の伝票で処理していました。荷主ごとに品目のコードが別々に登録されていたためです。

設計の選択肢は2つです。

選択肢	中身	向いている場合
A：荷主ごとの品目コードをそのまま移す	今のコード体系を変えない	移行の手間を最小にしたい、客先との帳票のやりとりがコードに依存している
B：「製品（共通）×持ち主（荷主）」に分ける	品目は共通にし、在庫の持ち主を別の項目で持つ	切り替えを1回の操作にしたい、製品単位で横断して集計したい

Bにすると、持ち主の付け替えだけで切り替えが済み、製品ごとの集計もしやすくなります。一方で、過去のデータの移し替えや、客先向けの帳票の作り方に影響します。この案件では、決めきらずに論点として残し、客先の業務担当の方と確かめる項目にしました。どちらが正しいかは業務によって変わるので、決める前に両方の影響を並べることが大切です。

出荷から請求まで、転記をなくすには？

客先ごとの運賃表と保管料をマスタにする

運賃は客先ごとに表が違い、保管料も客先ごとに条件が違っていました。これをExcelで計算して手で打ち込む限り、出荷の記録と請求は別々のものになります。そこで、客先ごとの運賃表と保管料の単価をマスタとして持ち、出荷の記録から運賃を計算して、請求書にそのまま載せる形にします。

運賃は、客先に請求する額と運送会社に支払う額の両方を持ち、差額を確かめられるようにしました。保管料は客先ごとの条件がまちまちで、すべてを計算式に落とすと、かえって扱いにくくなるおそれがありました。そのため、自動計算と手入力を選べる形にしています。全部を自動にすることが目的ではなく、転記と計算ミスを減らすことが目的です。

帳票は「作り直す」のではなく「出力する」

客先へ毎月出す受払月報は、日ごとの出荷の履歴、ロット、有効期限、ケース数、残高をまとめたものです。在庫を動きで記録していれば、月報はそこから客先ごとに出力するだけになります。請求書も同じで、システムの記録から出力し、Excelで作り直す作業をなくすことを目標にしました。

一本化は、どの順番で進めればいいのか？

範囲を段階に分ける

受注から請求までを一度に入れ替えようとすると、費用も現場の負担も大きくなります。この案件では、次のように段階を分けて考えました。

1. 第1段階：今システムで動いている包装・出荷・請求のまわりを移し、在庫を正しく直せる仕組み（動きの記録・調整・訂正）と、運賃・保管料・月報の自動化を入れる。受注の手入力と納期の通知もここに含める
2. 第2段階：原料・資材の入庫から生産工程までをつなぎ、受注に対して原料や在庫がどれだけ残っているかを見えるようにする。受注書のAI読み取りもこの段階で検討する

第2段階を後回しにしても困らないよう、データの構造は最初から入庫〜生産を足せる形にしておきます。

現場の負担を設計に入れる

基幹システムの入れ替えでは、日々の業務を回しながら移行の作業も進めることになります。そのため、旧システムと新システムの二重入力を長く求めない、受け入れの確認を短い期間にまとめる、といった現場の負担の上限を、機能の要件と同じ重さで扱いました。

実物の画面で確かめ、仮の仕様は「仮」と書く

要件は、課題・要件・前提・論点・決定待ちの5つに分けて整理し、そのうえで試作の画面を作って照らし合わせました。運賃表の構造や保管料の計算式など、まだ資料をいただいていない部分は、画面に「仮定」と表示して、確定した仕様と混ざらないようにしています。前述のロットの自動選択のように、試作で入れた仮の仕様が要件とずれていたことも、この照らし合わせで見つかりました。

システムどうしをつなぐときに起きやすい落とし穴は、CRMと生産管理の連携で起きた5つの落とし穴にまとめています。

一本化を検討する前のチェックリスト

• 受注・入庫・在庫・生産・出荷・請求のうち、システムで動いている区間とExcelの区間を書き出した
• システムの機能が使われなくなった区間について、使われなくなった理由を現場に聞いた
• 客先ごとの受注書を集め、共通の受注データに必要な項目を決めた
• 品目ごとの単位の換算（kg・袋・ケースなど）を整理した
• 在庫が「残高の上書き」か「動きの積み上げ」かを確かめた
• 過去の入力を訂正したとき、残高と履歴がどうなるかを確かめた
• ロット・有効期限・預かり在庫の持ち主を、項目として持てるか確かめた
• 客先ごとの運賃表・保管料の条件を集めた
• 第1段階と第2段階の範囲を分け、後から足せるデータ構造かを確かめた
• 移行期間に現場へかかる負担の上限を決めた

まとめ

受注Excelが客先ごとにバラバラでも、受注・在庫・出荷を一本につなぐことはできます。要点は、客先の書式を変えようとするのではなく受け取ってから寄せること、在庫を動きで記録して後から正しく直せるようにすること、そして客先ごとの条件をマスタにして転記をなくすことです。

受注後の工程を営業側から見える化する考え方は個別受注生産の案件管理を仕組み化する方法で、Excel管理をどこまで続けられるかの見極めはエクセル案件管理の限界で解説しています。営業から受注後までの全体の進め方は営業DXの全体像をご覧ください。

受注から請求までの流れを整える支援は、受注プロセス管理で行っています。

よくある質問

客先ごとに受注のエクセルの書式が違います。書式を統一してもらうべきですか？

お願いできる客先にはお願いしてもよいですが、それを前提にすると一本化は進みません。客先の書式はそのまま受け取り、社内で共通の受注データの形に寄せる設計にします。共通の形に必要なのは、取引先、品目、月ごとの数量、単位、納期、ロットの指定の有無といった項目です。単位（kg・袋・ケース）の換算は品目のマスタに持たせておくと、客先によって単位が違っても同じ数量として扱えます。

AI-OCRで受注書を自動で取り込めますか？

読み取って下書きを作るところまでは期待できますが、そのまま登録する設計はおすすめしません。客先ごとに書式が違うため、書式のパターンごとに読み取り結果を確かめる期間が必要です。読み取った内容を人が確かめてから登録する一手間を残し、まずは受注の手入力と納期の管理を先に整えるのが現実的です。

システムの在庫と実際の在庫が合いません。何から見直せばいいですか？

まず、在庫をどう記録しているかを確かめてください。月ごとの残高を上書きする方式だと、過去の入力誤りを直しても残高に反映されず、ずれが残り続けます。入庫・出庫・調整の一つひとつを記録として積み上げ、残高はそこから計算する方式に変えると、過去の訂正が残高に反映され、いつ誰が直したかの履歴も残せます。

受注から請求まで、一度に全部システム化すべきですか？

一度に全部を入れ替える必要はありません。今システムで動いている範囲と、Excelで回している範囲を分け、在庫の正しさと請求に直結する部分から先に移します。原料の入庫や生産工程の管理は、後から足せるデータ構造にしておけば、段階的に広げられます。

この記事の内容は、導入して効果が出た事例ですか？

いいえ。基幹システムの刷新を検討している受託製造業の要件整理で分かったことと、設計の考え方をまとめたものです。導入後の効果を示すものではありません。