2026.09.11 17 人が閲覧（直近 30 日） ERP

生産管理の業務フローとは？受注から出荷までの七工程と例外処理・システム化の判断

注文は入っている。図面もある。それなのに「いつ着手するか」が決まらず、現場が手待ちになる。原因は、営業と生産管理と購買のあいだで、どの情報がいつ確定するのかが共有されていないことがほとんどでした。この記事では、受注登録から出荷・売上計上までの業務フローを七つの工程に分け、各工程で何が確定し次へ何を渡すのかを整理しました。そのうえで、見込生産と受注生産で流れの先頭が入れ替わる理由、特急受注や設計変更といった例外をフロー図のどこに書き込むか、描いた図をシステムの要件へ変換する手順までを扱います。製品の機能比較や選び方は生産管理システムとはの記事に譲り、ここは業務の流れそのものに絞りました。

まとめ：七工程に分け、例外を書き込み、要件へ変換する

先に結論を置きます。業務フローの整理がうまくいった現場は、次の五点を押さえていました。

工程は七つに割ると過不足がない：受注登録、生産計画、所要量展開と資材調達、製造指示、実績収集、検査、出荷・売上計上。細かく割ると図が読めず、粗いと部門間の受け渡しが隠れます。
境目は「何が確定したか」で引く：切れ目は部署の境界ではなく、数量・納期・仕様・原価のどれかが確定した瞬間に置きます。部署で割った図は、一部署が二役を持つ会社で破綻しました。
フローの先頭は生産方式で入れ替わる：見込生産は需要予測、受注生産は受注登録、個別受注設計は設計が先頭。複数方式が同居するなら図も方式ごとに分けます。
標準フローより例外の記述で差がつく：特急受注、設計変更、不良、欠品、分納。この五つを本流に矢印として書けていない図は、要件定義でほぼ書き直しになりました。
図は三つに変換して初めて要件になる：名詞をマスタ、動詞をトランザクション、条件文をトリガーへ割り当てる。この変換をしていない図は、きれいでも見積りの材料になりません。

逆に、扱う品目が十数点で受注が月に数十件、計画を立てる人と現場を回す人が同じなら、フロー図を作り込む必要はありません。表計算の受注一覧と朝の打ち合わせで足ります。図が要るのは、引き継ぎと例外処理が口頭で回らなくなった時点からでした。

受注から出荷までの生産管理業務フロー七工程と各工程で確定する情報

七つの工程を順に見ていきます。大事なのは工程の名前ではなく、各工程の出口で何が確定し、次へ何を渡すのかという受け渡しの中身です。

受注登録で確定させる数量・納期・仕様と後工程へ渡す情報の線引き

受注登録の出口で確定させる項目は、品目コード、数量、回答納期、仕様や図番、出荷先、単価の六つです。このうち生産側へ渡すのは品目コード・数量・回答納期の三つに絞ります。単価や与信は販売管理側の情報で、製造の指示には要りません。

つまずくのは回答納期です。営業が顧客へ答えた希望納期と、生産側が能力を見て回答できる納期は別物でした。これを同じ欄に入れている会社では、計画担当が「どちらの日付を守るか」を毎回電話で確認していました。希望納期と回答納期を別項目に分け、回答納期は生産計画の工程を通ったあとに確定するとフロー上で明示します。

もう一つは内示と確定注文の扱いです。自動車部品や電機の取引では、数か月先までの内示数量が先に届き、直近分だけが確定注文に変わります。内示を受注として登録すると、引き当てと売掛の両方が狂いました。内示は計画の入力情報、確定注文だけが受注登録。この線引きをフローの入口に置きます。

生産計画と所要量展開が決める製造数量・着手日・部品必要量の算出

受注と内示を集めて基準生産計画をつくり、そこから所要量展開を回して製造オーダーと購買オーダーを生成する。この二段構えが計画工程の中身です。基準生産計画は完成品を「いつ・いくつ」つくるかの一覧で、所要量展開は部品表と製造リードタイムを使って、その完成品に必要な部品を階層ごとに割り出して着手日を逆算する計算でした。

計算に必要な入力は四つあります。部品表の構成と員数、工程ごとのリードタイム、現在の在庫数量、そして発注済みで未入荷の手配残です。このうち手配残を計算に入れていないと、同じ部品を二重に発注します。部品表の員数が図面と合っていないと、必要数が丸ごとずれます。所要量展開の精度は計算式ではなく、この四つの入力の鮮度で決まりました。

計画の刻みは週次から始めます。日次で回すには実績が日次で上がってくる必要があり、そこが整う前に日次計画へ踏み込むと、計画と現場のズレを毎日つくることになりました。

資材調達から製造指示へ渡すときに詰まる在庫引当と欠品時の対処法

所要量展開が出した購買オーダーを発注に変え、入荷した部材を製造オーダーへ引き当てる。ここが部門をまたぐぶん、最も滞りやすい区間です。

引き当ての設計で先に決めることは一つ、引き当てるタイミングです。受注時点で在庫を押さえると営業は安心しますが、キャンセルが多い商材では在庫が長く塞がります。製造指示の時点で押さえる方式なら在庫回転は良くなるかわりに、直前で欠品が判明する頻度が上がりました。キャンセル率と部材の調達リードタイムを見て決める設計判断です。

欠品が出たときの分岐も、フローに書いておきます。実務で使われる手は、代替品への振り替え、他オーダーからの引き当て変更、着手日の後ろ倒し、そして顧客への納期変更依頼の四つでした。この順に試すのか、金額や顧客区分で順番を変えるのかを決めておかないと、担当者ごとに判断が割れます。発注から検収・支払までの流れ自体は購買側の領域なので、購買管理の業務フローを扱った記事で別に整理しています。

製造進捗の実績収集と検査・出荷で残す記録の粒度と売上計上の起点

製造指示を出したあとは、実績が返ってこないと計画を回し直せません。収集の粒度は、工程完了単位・ロット単位・個体単位の三段階から選びます。粒度を上げるほど現場の入力負荷が増えるため、トレーサビリティを法規制や顧客から求められている品目だけ個体単位にする混在設計が実務的でした。

ここで足を引っぱるのが、データは集めているのに使えていないという状態です。経済産業省ほか2省が公表した2026年版ものづくり白書の概要19ページでは、一連の製造プロセスにおけるデータを何らかの目的で取得している事業者は7割弱ある一方、取得したデータを使って効果が得られた事業者は約4割にとどまり、企業間のデータ連携は2年前からほぼ変化がないと報告されています。取得と効果のあいだに開いた3割ぶんの差を生むのは、集める仕組みの不足ではなく、集めた実績を計画へ戻す経路がフローに描かれていないことでした。実績収集の工程を設計するときは、集めた数字がどの工程の判断に戻るのかを矢印で結んでおきます。

最後は売上計上の起点です。出荷した時点で売上を立てるのか、顧客の検収をもって立てるのか。この違いは会計側の締め処理だけでなく、出荷工程の出口に検収登録という手順を追加するかどうかというフローの形にも影響します。原価をどの単位で集計するかと合わせて設計する必要があり、原価管理システムとはの記事で扱った原価の集計単位と突き合わせて決めます。

見込生産・受注生産・個別受注設計で分かれる業務フローの分岐点と判断

七工程の並びは、生産方式によって先頭が入れ替わります。同じ図で三方式を表現すると分岐だらけで読めなくなるため、方式ごとに図を分けるのが原則です。

見込生産と受注生産でフローの先頭が入れ替わる需要予測と受注登録

見込生産では需要予測が先頭に立ち、予測にもとづいて生産計画を立て、完成品を在庫として持ち、受注は在庫からの引き当てだけで終わります。受注生産では受注登録が先頭で、受注を受けてから生産計画に入ります。この違いが出る境目が、どこまでを在庫で待たせるかという切り分け点です。完成品で待つのが見込生産、部材や中間品で待つのが受注生産と整理すると、図の描き分けが決まります。

厄介なのは、一つの工場に両方が同居する場合です。定番品は見込生産、特注品は受注生産という会社は珍しくありません。この場合、品目マスタに生産方式の区分を持たせ、区分で受注登録後の経路を分けます。区分を持たず担当者の記憶で振り分けていた現場では、定番品なのに受注の都度つくる運用が残り、リードタイムが二週間伸びていました。

生産方式の呼び名は社内の慣用語になりやすく、同じ言葉が部署で違う意味を持つことがあります。用語はJIS Z 8141「生産管理用語」に規定があり、現行版は2022年3月22日改正の2022年版です。社内で定義を作る前に、規格の用語に合わせておくと、外部のベンダーや監査とのやり取りで説明が省けます。

個別受注設計で設計工程が先頭に入るときのフロー全体の組み替え

装置産業や建築設備のように、受注してから設計を起こす個別受注設計では、七工程の前に設計工程が入ります。ここでフローの性格が変わります。受注時点では部品表が存在せず、部品表が確定するまで所要量展開が回せないからです。

実務では部品表を一括で確定させず、長納期品から段階的に確定させます。受注直後に長納期部材だけを先行手配し、残りは設計完了後にまとめて手配する。この二段階の手配をフロー図に描き込まないと、設計待ちで全部材の発注が止まり、納期が設計期間ぶんそのまま後ろへずれます。

もう一つは原価の持ち方です。個別受注設計では製番や工事番号ごとに原価を集計するため、資材の払い出しも実績の収集も製番に紐づきます。品目別に集計する見込生産の設計を持ち込むと、案件ごとの損益が出せません。図のどの工程で製番が採番され、どこまで引き継がれるのかを明記しておきます。

標準フローから漏れる例外処理と差し戻し経路を書き込むときの判断

解説記事で手薄になりがちな領域です。標準の流れは誰が描いてもほぼ同じ形ですが、現場が時間を取られているのは例外処理のほうでした。

特急受注・納期変更・分納が割り込んだときの差し込みルールの決め方

割り込みは必ず起きます。問題は、割り込んだときに誰が何をどこまで動かしてよいかが決まっていないことです。決めるべきは三点あります。差し込みの判断者、押しのけてよい既存オーダーの範囲、そして押しのけた結果として遅れる案件への連絡経路。

判断者は金額や顧客区分で段階を分けると運用が回ります。空き能力へ入るだけなら計画担当の裁量、既存オーダーを後ろへずらすなら生産管理責任者、回答納期を変えるなら営業を含めた合議。この三段階を図の分岐に書いておけば、現場は毎回の判断を上へ上げずに済みました。

分納は出荷工程の分岐として描きます。一つの受注を複数回に分けて出荷すると、出荷実績と請求が一対一で対応しなくなり、受注残の数え方も変わります。受注番号に出荷明細を複数ぶら下げるか、受注そのものを分割するか。前者は履歴が追いやすく、後者は既存の帳票を変えずに済みます。

設計変更・不良発生・欠品で生じる差し戻し経路をフロー図へ書き込む手順

例外を別紙の手順書に逃がすと、フロー図は読みやすくなるかわりに、システム要件としては使えなくなります。差し戻しは本流の図に矢印として描きます。

不良が出たときの分岐は、手直しして同じオーダーで続ける、再製造オーダーを起こす、廃棄して数量を減らす、の三通りです。それぞれ在庫と原価への影響が違うため、どの分岐を通ったかを記録に残す必要があります。設計変更では、変更の有効日と切り替えロットをどう決めるかを図に書きます。手持ち在庫を使い切ってから切り替えるのか、即日で切り替えて旧部材を廃棄するのか。この判断を図に描いていないと、変更のたびに個別判断になりました。

描き方の手順としては、まず標準フローを一本描き、次に各工程の右肩に「ここで止まる原因」を書き出し、その原因ごとにどの工程へ戻るかを矢印で引く、という順で進めます。表記法としてOMGが公開しているBPMN 2.0.2（2014年1月公開・ステータスFormal）を使うなら、この差し戻しは境界イベントで表現できます。エラー用と時間経過用の二種類だけ覚えておけば、不良による差し戻しと納期超過による差し戻しは書き分けられました。

業務フロー図をシステム要件へ変換する手順とマスタ・帳票の洗い出し

フロー図は要件定義の材料であって、要件そのものではありません。図のままベンダーへ渡すと、見積りは概算の域を出ません。

業務フロー図から抜き出すマスタ・トランザクション・トリガーの三点

変換は三つの品詞に対応づけると機械的に進みます。図に現れる名詞のうち繰り返し登場するものがマスタ、工程の箱そのものがトランザクション、分岐の条件文がトリガーです。

生産管理のフローなら、名詞から出てくるマスタは品目、取引先、部品表、工程、設備、倉庫とロケーション、単位の七つが基本形になります。箱から出てくるトランザクションは受注、生産計画、製造オーダー、購買オーダー、入出庫、作業実績、検査記録、出荷の八つ。分岐の条件文からは、在庫が引当可能数を下回ったら購買オーダーを起こす、といったトリガーが拾えます。

この三つを表に落とせば、そのまま画面一覧とデータ項目の下書きになります。数が確定すれば、パッケージで足りるのか個別開発が要るのかの判断材料にもなりました。機能単位で製品を見比べる段階へ進むなら、生産管理システムの機能と種類を整理した記事と突き合わせます。

BPMN記法をどこまで使うかの線引きと現場が読める図の粒度の目安

BPMN 2.0.2には100種類を超える記号が定義されていますが、現場レビューで使う記号は五つに絞ります。開始イベント、終了イベント、タスク、排他ゲートウェイ、そして部署を表すレーンです。ここに前述の境界イベント二種類を足した七記号で、生産管理のフローはほぼ描けました。

記号を増やすと、図の正しさは上がっても現場の人が読めなくなります。読めない図はレビューで指摘が出ず、そのまま要件定義へ通り、稼働直前に「この流れは実態と違う」と判明します。図の目的は正確な記述ではなく、現場から誤りを指摘してもらうことでした。

粒度の目安は、一枚の図に収まる工程の箱を15前後に抑え、A3用紙一枚で読み切れる範囲にすること。超えたら下位のフローへ切り出して階層を分けます。ただし三階層より深くすると、図同士の整合を保つ手間のほうが大きくなりました。

部門をまたぐ承認と権限をフロー図へ落とし込むときの三つの確認点

レーンを部署で分けたら、レーンをまたぐ矢印には必ず承認が付いているかを確認します。確認点は三つです。誰が承認するか、承認時に何のデータを見るか、承認後に何を変更できるか。

二番目が抜けやすいところでした。承認者が画面で見るべき情報が定義されていないと、開発後に「この画面では判断できない」という差し戻しが起きます。納期変更の承認なら、変更前後の日付だけでなく、後ろへずれる他オーダーの一覧が同じ画面に要ります。三番目は権限設計に直結する項目でした。承認済みの製造オーダーを誰が取り消せるのか、取り消した記録は残るのか。製造業の監査や品質システムの要求では、承認と変更の履歴が残ることを求められる場面があります。

不在時の代理承認も、図の段階で決めておきます。代理を作らずに運用へ入ると、承認者が休んだ日に紙の回覧が復活し、システムの外へ業務が漏れました。

業務フロー作成でつまずく場面と着手順序の判断基準を条件別に整理

業務フローの整理は、やりすぎても足りなくても同じだけ損をしました。

業務フローを書かずにパッケージを選んだ案件で起きる作り直しの例

製品デモを先に見て、機能一覧で比較して決める。この順序で進めた案件は、稼働の三か月前あたりで追加開発が膨らみます。理由ははっきりしていて、デモで見えるのは標準フローだけだからです。特急受注の差し込み、分納、製番単位の原価集計といった、自社にとっての当たり前は、デモの筋書きには出てきません。

選定の前に必要なのは、完成した図ではなく、方式ごとの一本の流れと、例外が年に何件発生しているかの数字です。この二つがあれば、デモの場で「うちはこの分岐がありますが、標準機能で処理できますか」と聞けます。聞かずに進めた結果として何が起きるかは、生産管理システムの導入が失敗する原因を整理した記事で個別の事例として扱っています。

完璧な業務フロー図を作り込む前に実装へ切り替えるべき二つの条件

逆側の失敗も同じくらい見かけます。フロー図の作り込みに半年かけ、その間に組織改編と主力製品の入れ替わりが起きて、完成した図が実態と合わなくなるパターンです。

切り替える条件は二つだけです。一つ、主要品目の8割をカバーする流れが一本描けていること。二つ、例外が何種類あり、それぞれ年に何件発生しているかを数えられていること。この二つが揃ったら、残りの例外を図に落とし込む作業は止めて、プロトタイプか試験運用へ進みます。件数の少ない例外は、画面の上で動かしてみたほうが早く判明しました。

図を完成させること自体が目的になった時点で、その図は要件定義の材料としての寿命を終えていました。

表計算のまま運用を続けてよい規模とシステム化へ移る判断の分岐点

システム化を見送ってよい条件を先に挙げます。品目数が数十点、月あたりの受注件数が百件未満、計画を立てる人と現場を回す人が同じか隣の席にいる。この三つが揃っているなら、表計算と口頭確認のほうが速く、安く、正確でした。フロー図もシステムも要りません。

分岐点は件数ではなく、確認の往復が発生する回数で測ります。在庫がいくつあるか、あの注文は着手したか、この部材はいつ入るか。この三つが日に何度も飛び交うようになったら、情報が個人の頭の中にあって共有されていない状態で、ここがシステム化の入り口でした。もう一つの分岐点は、生産方式が二つ以上混在し、品目によって流れが変わり始めたときです。人の記憶で振り分けている限り、担当者の異動で運用が崩れます。

どちらの分岐点も越えていて、既製のパッケージでは自社の分岐を吸収できないと分かった場合は、業務に合わせて設計する方式を検討します。整理した業務フローをそのまま要件の形にして見積りを取る進め方については、生産管理システム開発のサービスページで対応範囲を示しています。フロー図が途中でも、方式ごとの一本の流れと例外の一覧があれば、概算の範囲は詰められました。

よくある質問

業務フローの整理で判断が分かれやすい質問を五つ挙げます。

生産管理の業務フローは何工程に分けるのが一般的ですか？

受注登録、生産計画、所要量展開と資材調達、製造指示、実績収集、検査、出荷・売上計上の七工程で割ると、部門間の受け渡しが漏れずに表現できます。書籍や製品資料では四工程や九工程での分け方も見かけますが、数そのものに正解はありません。判断の基準は、数量・納期・仕様・原価のいずれかが確定する瞬間が工程の切れ目になっているかどうかです。

業務フロー図は表計算ソフトとBPMNツールのどちらで作るべきですか？

最初の一本は表計算ソフトや作図ソフトで十分です。現場のレビューで矢印を何度も引き直す段階では、書き換えやすさが精度に勝ります。BPMN 2.0.2のような標準記法へ移すのは、要件定義の資料としてベンダーへ渡す段階からで間に合います。標準記法の利点は、社外の相手と記号の意味を確認せずに済むことと、差し戻しを境界イベントとして正確に表せることの二点です。

生産管理と工程管理で業務フローの扱う範囲はどう違いますか？

工程管理は生産管理の一部にあたり、本記事の七工程でいえば製造指示から実績収集までの区間を担います。受注登録や購買、原価の集計は生産管理側の担当でした。範囲を混ぜて一枚の図にすると、現場の日程を動かせる裁量と、顧客との納期を動かす判断が同じ階層に並んでしまいます。二つの言葉の包含関係とシステムの守備範囲については、生産管理と工程管理の違いを整理した記事で個別に扱っています。

業務フローの作成は誰が担当すべきですか？

描くのは生産管理部門の実務担当者、レビューするのは各工程の現場担当者、という分担が回ります。情報システム部門やベンダーが主導すると、システムで実現できる形に寄った図になりました。逆に現場ごとに描かせると、部門間の受け渡しが誰の担当でもなくなって抜けます。全体を一人が描き、各部門が自分のレーンだけを検証する形が、手戻りが少なくて済みました。

業務フローを見直すタイミングはいつですか？

システム導入の検討時が最も多いものの、それ以外では主力製品の生産方式が変わったとき、生産拠点を増やしたとき、そして例外処理が月に十件を超えたときです。三つ目が見落とされやすい合図でした。例外の増加は標準フローが実態に合わなくなった兆候で、放置すると例外処理のほうが標準になります。年に一度、例外の件数を数えるだけでも、見直しの要否は判断できます。