◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 繁忙期の遅れは、受信・確認・在庫引当・納期回答・出荷指示の工程ごとに待ち件数と待ち時間を見て、人の判断待ちかシステムの動作待ちかに分けてから手を付ける
- 繁忙期前に、確認を軽くする注文と人が確認する注文の線引き、締め時刻、担当の代替体制を決め、前年の繁忙期の記録と照らして妥当性を確かめる
- 障害時の代替手段は、受付の台帳と原本の保管、復旧後の照合で二重受注を防ぎ、取引先との合意と書面の扱いを事前に確かめておく
- 運用を変えても縮まない待ちだけをシステム側の確認へ回す。取引先がFAXや電話で発注する限り、自社のシステムを強化しても転記は残る
- 繁忙期後は、最初の切り分けと同じ指標をルール変更の日付と対応づけて残し、次回どちらを先に直すかの判断材料にする
目次

繁忙期に受注確認と納期回答が追いつかないとき、遅れは注文のどの段階で起きているか
繁忙期に入ってWeb受発注システムへの注文が一気に増え、受注確認や納期回答が追いつかない。
取引先からの「届いていますか」「いつ出せますか」という問い合わせに追われて、処理がさらに遅れる。
製造業の受注の現場がこうなったとき、システムの増強より先に手を付けられることがあります。
遅れている工程の切り分けと、繁忙期前に決める運用ルールです。
工程ごとの待ちを見たうえで、自動処理と人の確認の線引き、締め時刻、取引先への事前周知を決めます。
それでも残る待ちだけをシステム側の確認に回すと、何から直すかの優先順位を付けやすくなります。
受信・確認・在庫引当・納期回答・出荷指示のどこで待っているか
問い合わせが増えてくると、受注業務の全体が遅れているように感じます。
実際には、注文がとどまっている場所は工程ごとに違います。
全体を一度に速くしようとすると、詰まっていない工程にまで人や手間を割くことになります。
最初にしたいのは、注文がいまどの工程で待っているかを分けて見ることです。
受注側の注文処理は、おおまかに次の5つの工程に分けられます。
- 受信:取引先が入力した注文がWeb受発注システムに届き、担当者が一覧で見られる状態になる
- 確認:品番・数量・単価・納期・納入先が取り決めどおりか、担当者が内容を見る
- 在庫引当:注文に対して、在庫や生産予定の数量を割り当てる
- 納期回答:出せる日を決めて取引先へ返す
- 出荷指示:倉庫や出荷担当へ、何をいつどこへ出すかを渡す
それぞれの工程で見る数字は二つです。
一つは待ち件数で、ある時点でその工程に残っている未処理の注文の数を指します。
もう一つは待ち時間で、前の工程が終わってからその工程が終わるまでにかかった時間です。
Web受発注システムの画面や出力データに、受信日時や回答日時、注文ごとの状態が残っていれば、そこから拾えます。
残っていない場合や、在庫引当を別の生産管理システムや表計算で行っている場合もあります。
そのときは1日に数回、各工程の未処理件数を手で数えて書き留めるだけでも、どこに注文がたまりやすいかの傾向は見えてきます。
二つの数字の組み合わせで、遅れの性質が変わります。
たとえば、在庫引当の待ち件数は少ないのに、納期回答の待ち時間だけが長い場合を考えます。
引当までは進んでいるのに回答が出ないなら、在庫が足りない注文について製造部門や生産管理へ「いつ作れるか」を確かめる時間が積み上がっている可能性があります。
この場合、受注担当を増やしても回答は早まりません。
見直す余地があるのは、製造側へ問い合わせる手順やタイミングのほうです。
反対に、受信の段階で注文が一覧に出てくるまで時間がかかる、画面の表示や検索が遅くて確認作業が進まない、といった待ちは、人の手順では縮めにくい種類のものです。
ここで分けておきたいのは、人の判断や確認を待っている遅れと、システムの動作を待っている遅れです。
前者は、繁忙期前に決める運用ルールで負担を減らせる可能性があります。
後者は運用を組み替えても残りやすいため、システム側の確認へ回す候補になります。
この切り分けは、工程を区切って見るための一つの案で、効果を測った公開データに基づくものではありません。
区切り方や数える時点は、自社の業務の流れに合わせて調整して構いません。
受注側と発注側で見る場所はどう違うか
ここまでの工程は、取引先から注文を受けて出荷までを回す受注側の流れです。
部品や資材を仕入先へWebで発注する購買担当の立場では、見る場所が変わります。
発注側で待ちが生じやすいのは、社内での発注承認と、仕入先からの納期回答を受け取ってから自社の生産計画へ反映するまでの間です。
仕入先の回答が遅れている場合、その遅れは相手側の工程にあるため、自社の手順を変えても縮みません。
回答待ちの件数と、それが自社の生産計画のどこに影響しているかを並べて見るところが出発点になります。
もう一つの違いは、システムをどちらが持っているかです。
自社でWeb受発注システムを運用している場合や、自社が契約しているサービスを使っている場合は、処理の記録や設定を自社側で見られます。
一方、取引先が用意した発注画面に自社が入って注文を見たり回答を入力したりする形では、自社から見えるのは画面上の状態だけです。
受信が遅いと感じても、その原因が先方のシステムにあるのか、自社の操作の順番にあるのかは、画面だけでは分けられないことがあります。
この場合は、自社の操作にかかる時間と、画面に注文が現れるまでの時間を分けて記録しておくと、先方へ相談するときの材料になります。
以降は、ここで分けた工程ごとの待ちを前提に、受注側の担当者が繁忙期の前と当日に何を決め、どう動くかを考えていきます。
▼ 図の内容を文字で読む
- 受信
- 確認
- 在庫引当
- 納期回答
- 出荷指示
繁忙期の前に決めておく運用ルール:自動処理と人の確認の線引き、締め時刻、担当の代替
自動で流す注文と人が確認する注文の分け方
人の確認を待っている工程が見えてきたら、次はその確認の対象を絞ります。
繁忙期に確認が追いつかなくなるのは、件数が増えた分だけ、すべての注文を同じ深さで見ようとするからです。
注文の中には、取り決めどおりの品番と数量で、在庫からそのまま出せるものがあります。
特注品や短納期の依頼のように、判断が要るものもあります。
前者を軽い確認で先へ進め、後者に人の時間を回すと、限られた時間を判断が必要な注文へ集めやすくなります。
分ける基準の案を表にまとめます。
ここでの「自動で流す」は、システムの設定で確認を省くことだけを指すわけではありません。
一覧の絞り込みで定型の注文をまとめて処理する運用も含みます。
表の右端に前提を置いたのは、この線引きが自社の商品や取引条件しだいで成り立たなくなるからです。
たとえば品目マスタで定番品と特注品が区別されていなければ、品目による振り分けはできません。
システムに条件付きで処理を分ける設定があるかどうかも、使っているサービスによって違います。
設定がない場合でも、同じ考え方は運用で再現できます。
注文一覧を条件で並べ替え、定型の注文をまとめて処理する担当と、例外を見る担当に分ければよいのです。
線引きが妥当かどうかは、前年の繁忙期の記録と照らすと見当が付きます。
確認の段階で差し戻しや問い合わせが発生した注文が、どの条件に当てはまっていたかを数えます。
確認を軽くする候補に入れた条件の注文で差し戻しが多く出ていたなら、その条件はまだ自動に回せません。
逆に、ほとんど修正が入っていない条件の注文に毎回同じ確認をしていたなら、そこが時間を空けられる場所になります。
締め時刻とリードタイムの決め方
締め時刻は、注文の扱いを分ける区切りです。
その時刻までに受信した注文は当日中に確認・回答し、それ以降の注文は翌営業日に回します。
繁忙期にこれを決めておく理由は二つあります。
担当者にとっては、その日に処理すべき注文の範囲がはっきりします。
夕方以降に届いた注文に追われて当日分が終わらない、という状態を避けやすくなります。
取引先にとっては、いつ送ればいつ回答が来るかの見通しが立ち、受信を確かめるための問い合わせを送る理由が減ります。
時刻は、後ろの工程から逆算して決めます。
出荷便の集荷時刻、倉庫が出荷指示を受け付けられる最終時刻、在庫データが更新されるタイミングなど、自社で動かせない時刻を先に並べます。
そこから、確認と在庫引当と納期回答にかかる時間を差し引いた時刻が、締め時刻の候補です。
繁忙期は1件あたりの処理時間が同じでも件数が増えるため、通常期と同じ締め時刻では当日中に回り切らないことがあります。
前年の繁忙期に、何時に受信した注文から翌日回しになっていたかを記録で見ると、現実的な時刻に近づけられます。
リードタイムを繁忙期だけ延ばすかどうかは、締め時刻より影響が大きい判断です。
延ばせば、回答の遅れや納期の約束違反は起きにくくなります。
その代わり、取引先の発注計画にも影響が及びます。
延ばす場合は、取引先が自社側の計画を組み直せるよう、早めに伝える必要があります。
担当が欠けたときの代替体制
繁忙期は、担当者が一人休むだけで特定の工程が止まりやすい時期でもあります。
止まりやすいのは、二種類の工程です。
その人しか知らない取引先ごとの例外ルールがある工程と、その人にしか操作権限がない工程です。
たとえば、ある取引先の注文は納入先コードの付け方が独特で、毎回担当者が手で直しているとします。
この手直しは、記録に残っていない限り代わりの人には分かりません。
代替体制で決めておきたいことを挙げます。
- 工程ごとに、代わりに処理する人を一人以上決める
- 代わりの人に、Web受発注システムの操作権限を繁忙期前に付けておく
- 取引先ごとの例外ルールを、注文を見ながら参照できる場所に書き出す
- 承認が必要な注文について、承認者が不在のときの代わりの承認者を決める
権限の付与は、システムの管理者や提供事業者への申請が要る場合があり、繁忙期に入ってからでは間に合わないことがあります。
代わりの人が繁忙期の前に一度、実際の注文を処理してみると、書き出した手順に抜けがあるかどうかが分かります。
見落としやすいのは、本人にとって当たり前すぎて手順書に書かれていない操作です。
| 見る条件 | 確認を軽くする候補 | 人が確認する候補 | 成り立つ前提 |
|---|---|---|---|
| 品目 | 定番品・継続品 | 特注品・仕様指定のある品 | 品目マスタで定番品と特注品が区別できる |
| 数量 | 取引先のふだんの範囲に収まる | ふだんより大きく外れる | 取引先ごとのふだんの数量が分かる |
| 希望納期 | 標準のリードタイム内 | 標準より短い・日付指定が厳しい | 標準のリードタイムを決めている |
| 取引先 | 継続取引で条件が決まっている | 新規・与信の枠を超える可能性がある | 与信の枠や取引条件を管理している |
▼ 図の内容を文字で読む
- 動かせない時刻を並べる
- 処理にかかる時間を差し引く
- 締め時刻の候補を出す
- 前年の記録で見直す
注文が集中した当日の処理順:入力ミスと取りこぼしを防ぎ、障害時に代替手段へ切り替える
当日の処理の優先順位
注文が集中した当日に届いた順で処理していくと、締め時刻や出荷便に間に合わせるべき注文が後ろに埋もれます。
繁忙期前に決めた線引きと締め時刻を使って処理の順番を決めておけば、その場で迷う時間が減ります。
順番の一例を示します。
最初に受信漏れを見るのは、後から見つかった取りこぼしほど取り戻しにくいからです。
その日の処理を始める前に、前日の締め時刻以降に届いた注文、前日に保留にした注文、一覧の検索条件から漏れている注文をまとめて把握します。
次に出荷便に間に合わせる注文を処理するのは、ここを逃すと納期そのものが1日ずれるためです。
人の確認が必要な注文より前に、自動処理や一括処理で流した注文の結果確認を置いています。
エラーで止まった注文を早めに拾い、例外処理の列へ移すためです。
問い合わせの受け方も、処理の順番と一緒に決めておきます。
注文を処理している担当者が電話やメールの問い合わせにも答えていると、そのたびに手が止まり、処理中の注文の確認が途切れます。
問い合わせを受ける人を一人決め、その人が注文ごとの状況を見られる一覧を共有しておくと、処理担当は手を止めずに済みます。
一覧には、注文番号、いまどの工程にあるか、回答予定がいつかの三つがあれば、受信の確認や回答時期の問い合わせにはその場で答えられます。
確認を二重にする場所と暫定回答の出し方
入力ミスを抑えようとしてすべての注文を二人で確認すると、確認そのものが新しい待ちになります。
二重にする場所は、誤りが後の工程で見つかりにくく、見つかったときの手戻りが大きいところに絞ります。
受注側で言えば、次のような箇所です。
- FAXや電話で受けた注文を、Web受発注システムや社内システムへ手で入力するところ
- 品番・数量・納入先を、取引先の指定と照らすところ
- 納期を、標準のリードタイムより短い日付で回答するところ
- 出荷指示を、受注データとは別の帳票や画面へ写すところ
共通しているのは、人が値を写したり、例外の判断をしたりする場面です。
取引先が入力したデータがそのまま自社の処理へ流れる部分では写し間違いが起きにくく、二重確認の必要は相対的に小さくなります。
転記が入る場所は、その転記をなくせるかどうかを繁忙期後に見直す対象として、記録に残しておく価値があります。
当日中に在庫や生産の見通しが立たず、確定した納期を返せない注文もあります。
そのときは何も返さずに置いておくより、受け付けたことと、確定回答を返す予定の日時を先に返します。
暫定回答で避けたいのは、確定した回答と取り違えられることです。
「受付済み・納期は〇日までに回答」のように、確定前であることが文面から分かる形にします。
社内の一覧でも暫定回答の注文に印を付け、期日までに確定回答を返せたかを追えるようにします。
暫定回答のまま確定されない注文が残ると、取引先は回答を待ち続け、結局は問い合わせとして返ってきます。
障害時にFAX・電話・メールへ切り替えるときの注意
Web受発注システムにつながらない、注文が届かないといった障害が起きたとき、FAX・電話・メールで注文を受ける代替手段に切り替えることがあります。
ここで起きやすい問題は二つです。
一つは、代替手段で受けた注文の記録が散らばり、後から何を受けたか追えなくなること。
もう一つは、同じ注文を二重に受けることです。
取引先がWebとFAXの両方で送ったり、復旧後にWebで送り直したりすると、これが起こります。
切り替えの流れを段階に分けると、次のようになります。
記録の要は、代替手段で受けた注文を一か所の台帳にまとめることです。
受付番号と受付日時、受けた手段、受けた人を付けておきます。
FAXの紙やメール本文は、後から内容を確かめられるよう原本として残します。
電話で受けた注文は口頭のやり取りしか残りません。
受けた内容を書面やメールで取引先へ返して確かめてもらうと、聞き違いを後から見つけやすくなります。
復旧した後は、代替手段で受けた注文と、Web受発注システム上の注文を突き合わせます。
品番・数量・納期・取引先が一致する注文が両方にあれば、二重受注の候補として取引先に確かめ、どちらを正とするかを決めます。
取引先へ代替手段を案内する時点で、障害中にFAXで送った注文は復旧後にWebで送り直さないよう伝えておくと、重複そのものを減らせます。
代替手段の使い方は、取引先と合意しておくことが前提です。
取引先によっては、電話での発注をしない取り決めや、決められた書式でしか発注しない社内ルールがある場合もあります。
また、発注内容をどの方法で伝え、どう残すかは、取引の形によっては法令上の書面の扱いに関わることがあります。
この点はここでは断定しません。
代替手段を決める段階で、公正取引委員会や中小企業庁が公表している資料、または自社の法務担当で確かめておくと安心です。
▼ 図の内容を文字で読む
- 受信漏れがないか確かめる
- 出荷便に間に合わせる注文を先に処理する
- 一括処理で流した注文の結果を確かめる
- 人の確認が必要な注文を処理する
- 確定できない注文へ暫定回答を返す
▼ 図の内容を文字で読む
- 切り替えを判断する
- つながらない状態を社内で確かめる
- 切り替えを決める人をあらかじめ決めておく
- 取引先へ知らせる
- 代替手段と送り先を伝える
- 復旧後にWebで送り直さないよう伝える
- 代替手段で受けて記録する
- 受付番号・受付日時・手段・受けた人を台帳に残す
- FAXの紙やメール本文を原本として残す
- 復旧後に照合する
- 代替手段で受けた注文とWeb上の注文を突き合わせる
- 二重受注の候補を取引先に確かめる
運用の工夫では足りず、システム側の見直しが必要になるのはどんな場合か
運用を変えても待ちが残る症状
締め時刻や線引き、当日の処理順を整えても、特定の工程で待ちが縮まらないことがあります。
そこで初めて、システム側に原因がある可能性を疑います。
この順番にするのには理由があります。
運用を見直さないままシステムの増強に進むと、人の判断待ちのように、システムを変えても縮まない待ちまで増強で解こうとしてしまうからです。
運用では解けにくい症状を、確かめる先と合わせて整理します。
表の症状に共通するのは、待ちの原因が人の作業の手前や外側にある点です。
担当者を増やしたり順番を入れ替えたりしても、そこには手が届きません。
たとえば画面の表示が遅い場合に処理担当を増やすと、同時に操作する人が増え、かえって待ちが長くなることも考えられます。
最初の切り分けで記録した待ち時間を時間帯ごとに並べると、件数の多い時間帯にだけ遅くなるのか、件数に関係なく遅いのかが分かります。
この違いは、事業者へ症状を伝えるときの材料になります。
事業者へ確認する項目
外部のサービスを使っている場合、確かめる先は、そのサービスの仕様書、利用契約、SLAです。
SLAはサービス品質保証のことで、稼働率や障害時の対応など、提供事業者がどこまでを約束しているかを定めたものです。
処理能力や障害時の扱いはサービスごとに異なり、一般的な目安で判断できるものではありません。
自社が使っているサービスの資料に当たる必要があります。
事業者へ問い合わせるときは、次の点を聞くと、運用で続けるか、設定や契約を変えるかの判断材料がそろいます。
- 同時に操作できる人数や、一定時間に処理できる注文件数に上限があるか
- 上限がある場合、繁忙期だけ引き上げられるか、そのときの費用や手続きはどうなるか
- 障害が起きたとき、利用者へどの手段で、どのくらいの時間で知らせる約束になっているか
- 受信日時や処理の状態などの記録を、利用者側で出力できるか
- 自動で振り分ける条件や締め時刻を、利用者側の設定で変えられる範囲はどこまでか
自社のサーバーで運用しているシステムなら、同じ項目を社内の情報システム担当や、開発・保守を委託している会社に確かめることになります。
相談の際は、症状の説明だけで済ませず、工程別の待ち件数と待ち時間を時間帯や日付とともに渡します。
そうすると、どこを調べればよいかの見当を付けてもらいやすくなります。
取引先の対応状況による限界
自社のシステムを見直しても、効果が届く範囲には限りがあります。
取引先がWeb受発注システムを使わずにFAXや電話で注文してくる限り、その注文を自社のシステムへ入力する作業は残るからです。
この制約は、国の取り組みを伝える報道でも示されています。
関係するのはEDIです。
企業間の受発注などのデータを、決められた形式で電子的にやり取りする仕組みを指します。
2021年の日刊工業新聞社の記事によると、中小企業共通EDIには、取引先も共通EDIを導入しなければ運用できないという課題があります1。
中小企業庁は、業界や企業ごとに仕様が異なる電子受発注システムとの取引を一元化できるデータ連携基盤の開発を構想していました1。
同じ記事は、この基盤によって電子受発注システムの導入率を、当時の約2割から2023年をめどに約5割へ引き上げる目標も伝えています1。
これは2021年時点の目標で、現在の導入率を示すものではありません。
それでも、電子受発注が広く行き渡っていない状況を前提に、国が手を打とうとしていたことは読み取れます。
自社の取引先も、Webで発注する先と、FAXや電話で発注する先が混在していることを前提に考えるのが現実的です。
そのうえで、受け方ごとの件数を確かめておきます。
取引先ごとの受け方の内訳が分かると、システム側の見直しの優先順位も変わります。
Webで受けている注文の比率が高いなら、自社のシステムの処理能力や設定の見直しが、待ちの解消に結び付きやすくなります。
FAXや電話の比率が高いなら、自社のシステムを強化しても転記の手間は残ります。
その場合は、取引先にWebでの発注を案内することや、手入力の二重確認を厚くすることのほうが先に効いてくる可能性があります。
なお、共通EDIやデータ連携の仕組みが使えるかどうかは、自社と取引先が使っている製品・サービスが対応しているかによります。
報道が伝えているのは共通EDIに準拠した製品・サービスを対象にした構想です。
自社の環境で何がつながるかは、利用中のサービスの資料で確かめる必要があります。
| 症状 | 運用で縮まない理由 | 確かめる先 |
|---|---|---|
| 取引先が送信してから一覧に注文が現れるまで時間がかかる | 人の手順より前で起きている | 提供事業者・情報システム担当 |
| 注文の多い時間帯に画面の表示や検索が遅くなる | 担当者を増やすと同時操作も増える | 提供事業者(同時利用や処理の上限) |
| 一括取込や連携でエラーになる注文が繁忙期に増える | 手で直す件数が注文件数とともに増える | 提供事業者・連携先の仕様 |
| 在庫の数字が古く、引当のたびに別の画面で確かめ直している | データの更新間隔が人の作業より遅い | 生産管理・在庫システムとの連携設定 |
| 取引先ごとに注文の形式が違い、転記が減らない | 自社側だけでは形式をそろえられない | 取引先の対応状況・連携の方式 |
▼ 図の内容を文字で読む
- 人の判断待ち
- システムを変えても縮まない
- 運用ルールの見直しで負担を減らす
- システム側に原因がある待ち
- 注文が一覧に現れるまで時間がかかる
- 画面の表示や検索が遅くなる
- 一括取込や連携でエラーになる
- 取引先の対応状況による限界
- FAXや電話で注文が来る限り入力作業が残る
- 受け方ごとの件数を確かめる
取引先へ繁忙期の対応をどう事前に伝えるか
周知に入れる項目と時期
社内で決めた締め時刻や代替手段も、取引先に伝わっていなければ、繁忙期の当日に問い合わせとなって返ってきます。
周知は、社内のルールを、取引先が自分の発注業務の中で使える形に置き換える作業です。
伝える項目は次の四つです。
- 締め時刻:何時までに受信した注文が当日扱いになるか
- 回答までの目安:受信から納期回答までにどのくらいかかるか。
リードタイムを延ばす場合は、その対象期間と日数 - 障害時の連絡先と代替手段:つながらないときにどこへ何で送るか、復旧後の再送の扱い
- 例外の扱い:特注品や短納期の依頼は、通常と回答の時期が違うこと
時期は、繁忙期に入る前で、取引先が自社側の発注計画を組み直せる余裕があるうちにします。
特にリードタイムを延ばす場合、取引先はその分だけ発注を前倒しする必要があり、相手の社内でも調整が要ります。
何週間前なら十分かは、取引先の発注の周期によって変わるため、一律には決められません。
月に一度まとめて発注する取引先なら、その前の発注の時点で伝わっている必要があります。
このように、相手の発注のタイミングから逆算して考えます。
伝える手段は、ふだん取引先と連絡を取っている経路に合わせます。
Web受発注システムにお知らせを表示する機能があればそこに載せ、あわせてメールや営業担当からの案内でも伝えます。
システムを開く人と発注の判断をする人が別の場合にも、届きやすくなります。
取引先の中で、注文を入力する担当と発注を決める担当が違う場合もあるため、どちらに届けば足りるかを相手ごとに考えておきます。
伝えた後の問い合わせの見方
周知の効果は、問い合わせの総数だけでは判断しにくい面があります。
繁忙期は注文そのものが増えるため、問い合わせの総数が増えていても、周知が届かなかったとは限りません。
そこで、問い合わせを内容で分けて数えます。
- 注文が届いているかの確認
- 納期回答の時期の催促
- 注文の変更・取り消し
- システムにつながらない、操作が分からないといった相談
周知した項目に対応する問い合わせが、注文件数に対してどう動いたかを見ます。
締め時刻を伝えたのに受信の確認が減らないなら、締め時刻と、回答が届くまでの時間の関係が伝わっていない可能性があります。
特定の取引先からの問い合わせが目立つなら、周知がその取引先の担当者に届いていないことも考えられます。
周知でどれだけ問い合わせが減るかは、取引先の構成や伝え方によって変わるため、自社の数字で確かめることになります。
内容別に数えておけば、次の繁忙期にどの項目の伝え方を変えるべきかが見えてきます。
繁忙期後に記録しておくこと:次回の準備へつなぐ振り返り
記録する指標
繁忙期が終わると、通常の業務に戻る忙しさで、振り返りは後回しになりがちです。
記録がないまま次の繁忙期を迎えると、また同じ場所で詰まり、同じ迷いから始めることになります。
記録する項目には、最初に遅れを切り分けるときに使った数字をそのまま使います。
新しく集計の仕組みを作らずに済むからです。
- 工程別の件数:受信・確認・在庫引当・納期回答・出荷指示の各工程で処理した注文の数と、日ごとの待ち件数
- 工程別の待ち時間:どの工程で、どの時間帯に待ちが長くなったか
- 誤りの件数:入力ミスや回答の誤りが、どの工程で見つかり、どの工程で生じていたか
- 問い合わせの件数:内容別に分けた件数
- 代替手段で受けた注文の件数:障害時にFAX・電話・メールで受けた件数と、二重受注になりかけた件数
誤りについては、見つかった工程と生じた工程を分けて残しておきます。
出荷指示の段階で見つかった数量の誤りが、実は確認の段階の転記で生じていた、ということがあるからです。
生じた工程が分かれば、二重確認を置いた場所が合っていたかを判断できます。
指標の定義、たとえば待ち時間をどこからどこまで測るかは、自社で決めて毎回そろえます。
定義が年ごとに変わると、前年との比較ができなくなるためです。
ルール変更と結果の対応づけ
数字だけを残しても、何を変えた結果なのかが分からなければ、次の判断には使いにくくなります。
記録しておきたいのは、締め時刻を早めた、定番品を一括処理に回した、問い合わせを受ける人を一人に絞った、といった変更です。
変えた日付とともに残し、その前後で関係する工程の数字がどう動いたかを並べておきます。
変更と結果を対応づけた記録があれば、次の繁忙期にどちらを先に直すかを判断しやすくなります。
運用を変えた工程で待ちが縮んでいれば、そのルールを次回も使い、必要なら準備を前倒しします。
運用を変えても縮まなかった工程は、運用では解けにくい症状と照らし、システム側の確認へ回す候補にします。
このとき、変更前後の数字を持って事業者や情報システム担当へ相談できるため、症状を口頭で説明するより具体的な話から始められます。
一つの繁忙期の記録だけでは、特定の大口注文や取引先の事情など、その年に限った要因との区別が付かないこともあります。
同じ項目を毎回残していくと、毎年同じ工程で詰まるのか、その年だけの事情なのかが分かるようになります。
そうなれば、システム側と運用側のどちらに手を入れるかも判断しやすくなります。
▼ 図の内容を文字で読む
- 工程別の数字を記録する
- 待ちの残る工程を切り分ける
- 運用ルールを変える
- 変更前後の数字を照らす
工程ごとの待ちを記録しても、それが運用で縮められる待ちなのか、システムの設定や契約の見直しが必要な待ちなのかは、社内だけでは判断が分かれやすいところです。
記録した待ち件数や待ち時間をもとに、どの工程から運用ルールを見直し、どの症状をシステム側の確認に回すかを一緒に整理できます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| 遅れの切り分け | 工程ごとの待ち件数と待ち時間で、人の判断待ちかシステムの動作待ちかを分ける |
| 自動と人の確認の線引き | 品目・数量・希望納期・取引先の条件と、前年の差し戻しの記録で決める |
| 締め時刻 | 出荷便や在庫データの更新など、動かせない時刻から逆算する |
| 障害時の代替手段 | 受付の台帳、原本の保管、復旧後の照合で二重受注を防ぐ |
| システム側の確認 | 運用を変えても縮まない待ちだけを、仕様書・契約・SLAの範囲で事業者に確かめる |
| 取引先への周知 | 締め時刻・回答までの目安・障害時の連絡先・例外の扱いを、相手の発注周期から逆算して伝える |
| 振り返り | 最初の切り分けと同じ指標を、ルール変更の日付と対応づけて残す |
次の繁忙期の準備は、振り返りの記録が新しいうちに始めるほど、ルールの見直しや取引先への周知に時間をかけられます。 振り返りの記録をもとに、次回の締め時刻や周知の内容、事業者へ確かめる項目を整理できます。
よくある質問
繁忙期の前に、いつまでに取引先へ周知すればよいか
一律の期限はありません。
目安は、取引先が自社側の発注計画を組み直せる時期で、相手の発注の周期から逆算して決めます。
たとえば月に一度まとめて発注する取引先なら、繁忙期直前の発注より前に伝わっている必要があります。
リードタイムを延ばす場合は、相手が発注を前倒しする調整も要るため、締め時刻だけを伝える場合より早めに伝えます。
注文を自動処理に回す条件は、どう決めればよいか
品目(定番品か特注品か)、数量がふだんの範囲か、希望納期が標準のリードタイム内か、継続取引で条件が決まっている取引先か、といった条件で分けるのが一つの案です。
妥当かどうかは、前年の繁忙期に差し戻しや問い合わせが出た注文がどの条件に当てはまっていたかで判断します。
条件で処理を分ける設定があるかは利用中のシステムによって違います。
設定がない場合は、一覧の絞り込みで定型の注文をまとめて処理する運用でも同じ考え方を取れます。
システムがつながらないときに、FAXや電話で受けた注文はどう記録するか
受付番号、受付日時、受けた手段、受けた人を付けて、一か所の台帳にまとめます。
FAXの紙やメール本文は原本として残し、電話で受けた内容は書面やメールで取引先へ返して確かめてもらうと、聞き違いを見つけやすくなります。
復旧後はWeb上の注文と突き合わせ、二重受注の候補を取引先に確かめます。
代替手段の使い方は取引先との合意が前提です。
法令上の書面の扱いに関わる場合もあるため、公正取引委員会や中小企業庁の公表資料、または自社の法務担当で確かめてください。
受注側と発注側で、繁忙期の対応はどう変わるか
受注側は、受信から出荷指示までの自社の工程のどこで注文が待っているかを見て、線引きや締め時刻で負担を減らします。
発注側の購買担当は、社内での発注承認と、仕入先からの納期回答を待つ時間が中心になります。
仕入先側の遅れは自社の手順では縮まないため、回答待ちの件数と生産計画への影響を並べて見ること、承認者が不在のときの代わりを決めておくことが出発点になります。
繁忙期後の振り返りは、どのくらいの期間のデータを見ればよいか
決まった標準はありません。
繁忙期の全体に加えて、比べる相手として通常期の同じくらいの期間と、前年の同じ時期の数字があると、繁忙期に特有の詰まりかどうかを判断しやすくなります。
期間の長さよりも、待ち時間などの指標の定義を毎回そろえることのほうが、比較には大切です。
画像の出典元