本投稿では、販売管理におけるサービス、外注のプロセスフローを解説しております。
この他にも販売管理関連の投稿はこちらにまとめがあります。また、販売管理に限らずSCM関連の記事はこちらのSCM関連記事まとめをご覧になってください。
Agenda
本投稿の想定読者
- SAP導入プロジェクトで販売管理領域を担当されるコンサルタント、システム部門の方
- SCM領域のうち、特に販売管理領域について知りたい方
期待できるメリット
- 販売管理領域における業務プロセスがわかる
- 販売管理領域のプロセスフローのサンプルが見れる
在庫販売とは
今回ご紹介する、販売管理のシナリオのうち、在庫販売とは、文字通り、在庫している商品や製品を販売するというシナリオのことです。
製造業や、流通業をイメージして頂くとわかりやすいかと思いますが、販売するものをあらかじめ作っておく、またはどこかのSupplierさんから仕入れておいて在庫にして倉庫などの保管しておき、それらを販売するというケースになります。
本投稿では、この在庫販売のシナリオを、プロセスフローを用いて解説していきます。
発注依頼～契約締結まで
それではここからは、プロセスフローを用いて各タスクをご紹介していきます。
なお、初めのステップとして、発注依頼をCustomerから頂くというところをスタートにしていますが、実際には営業担当者が顧客との間で見積もりをやり取りしていたり、商談を行っていたり、RFPに対して回答として提案を行っていたり、と前段階のステップがありますが、ここではそうした商談、見積提示、金額の交渉などはすでに終わっているものとして、発注依頼をCustomerから頂くところから始めさせて頂きます。
発注依頼
初めのステップは、Customerが自社に対して発注の依頼をかけてくれるところとなります。発注依頼は、様々な方法で行われますが、以下のような方法があるでしょう。
- メール等で発注の意思表示をしてもらう
- EDI等のシステム連携を通じて発注依頼を頂く
- 専用のポータルを通じて発注依頼を頂く（Amazon、楽天、等）
大きな製造業などは、毎週のように大量の部品や原材料等を購入することが一般的なので、自社とCustomerとの間でシステム連携を構築しておき、Customerが簡単に発注依頼をかけてくれるようにシステムを整備していることが一般的です。
（余談）何が発注依頼と扱われるのか
メール等で発注の意思表示をしてもらうケースですが、企業によって、何を発注の意思表示ととらえるのか、という考えはバラバラです。しかしながら、契約の締結をすることを考えると、最低限、以下の項目がそろっていること、あるいは認識が整合されていることが必要となります。
- 販売する品目
- 販売する品目ごとの数量
- 販売金額についての合意（単価、合計金額）
- 納期
与信チェック依頼
Customerから発注の意思表示を頂いたら、次は信用チェックの依頼を行います。営業さんは、もちろん発注の依頼を受けたらすぐにでも売りたいところですが、企業としては売ったはいいものの支払いがきちんとされない、というケースは避けたいので、ここで与信チェックを行います。
与信とは、そのCustomerが、どの程度なら売上債権を計上できるのか、という金額のことです。つまり、どの程度の金額ならば売りすぎにならないか、というもののことです。別の言葉では、与信枠、Credit Limitと呼ばれます。
たとえば、中小企業向けに100万円の品物を売ったとしても回収は出来るだろうと思えますが、1兆円の品物を売ったとして、本当にそれが回収できるのかというと、少し疑問ですよね。こうしたときに行うのが与信チェックであり、与信チェックとは、今受注しようとしている契約を仮に締結したとすると、事前に決めておいた与信の限界を、超えてしまわないか、というチェックをすることとなります。
システム的に情報を入力すれば一種運で終えることもできる与信チェックですが、ここでは業務的な視点でプロセスを整理しているので、営業さんが財務部門宛に与信チェックの依頼をおこなう、と表現しています。
与信チェック
営業さんから与信チェックの依頼があったら、販売しようとしている品物の合計金額と、Customerが持っている残りに与信枠を比較して、与信チェックを行います。
仮にここで与信の限界値を超えている、となった場合は、営業さんとしては販売契約の締結をあきらめるか、あるいは部門長や役員の特別承認をもらうことで販売を強行する、という流れとなります。
与信チェックがOKだった場合は、その結果が営業さんに伝えられ、後続のプロセスに進みます。
契約書発行
与信チェックが済んだら、次は契約書の発行を行います。契約書と一言で言っていますが、注文書、請書、契約書、等の様々な文書があります。ここでは、こうした文書の役割の違いなどは割愛致します。
契約書提示
契約書を発行したら、次はそれをCustomerに送付します。
このコミュニケーションも、メール等で送る方法や、EDI等のシステム連携の方法などがあります。
発注、契約締結
Customerが契約書を受領しました。Customerは、内容を確認して、問題が無ければ、契約締結のために契約書にサイン等を行い、返送を行ってくれます。こうして、Customerの側としては契約締結となります。
契約締結も、最近は電子署名が出来たりするので、以前のような紙の文書にサインして送り返す、という方法以外にも、メールで送られてきたリンクを開いて、立ち上がったWEBページ上でサインをする、あるいはやはりEDI連携などでサイン済みの契約書のPDFファイルをやり取りする、という方法があります。
契約書受領～納期回答まで
さて、ここまででCustomerが契約締結のために契約書を返送してくれました。次は、契約書を受領するところから、受注に対する納期回答を行うところまでの解説です。
契約書受領
Customerから返送頂いた契約書を受領します。これにて、自社側としても契約締結となります。
受注伝票作成
それでは、契約締結が済んだので受注伝票（SO：Sales Order）を作成します。受注し、契約を締結したことの証明となります。
もし、事前に見積書の発行などをシステムから行っている場合は、見積書の発行を行うシステムから、見積もり作成時に使用した情報をそのまま使用することで受注伝票が作成できます。
在庫引当依頼
今回は、在庫販売を行うケースなので、在庫の引き当てを依頼します。引き当てとは、作成した受注伝票に対して、そのCustomer向けに出荷するための在庫を特定すること、つまり在庫の確保を約束してもらうことです。
このタイミングで、在庫が用意できていれば、いつ出荷すればいつ頃Customerのもとに届くのか、という納期が計算できます。よって、在庫の引当依頼は、同時に納期の計算の依頼でもあります。
また、システム上で受注伝票を作成している場合は、都度都度在庫の引当依頼、納期回答の依頼をするのは手間ですので、自動で在庫の引き当てが行われ、納期回答が行われるように仕組みを整えておくことが一般的です。
在庫引当、納期回答
営業さんから在庫引き当ての依頼がされたら、倉庫の中にある在庫のうち、どれを受注伝票に引き当てるか、という点を物流、倉庫部門が決定します。それと同時に、Customerの住所などの情報から、いつ出せばいつ届くことになるのか、という納期を計算し、営業さんに回答します。
システム的に処理をしていれば、どの在庫を引き当てるか、そして納期はいつになるのか、という点は実際には物流・倉庫部門の人々が意識せずにシステムが処理をしてくれます。
ここでは、業務の視点でプロセスを整理しているので、その責任は物流・倉庫部門にあるため、このように表記しているという点をご理解ください。
納期回答
営業さんが、自社の物流、倉庫部門から納期の回答を受けとりました。その内容を、ここではCustomerに伝達します。
もし、契約締結後は営業さんはCustomerとやり取りをしない、というオペレーションを取っている企業であれば、物流、倉庫部門からCustomerに対して納期回答をするというケースもあるかもしれません。
この納期回答も、営業さんや物流・倉庫部門の人がメールや電話など連絡するケースもあれば、自動メールであらかじめ頂いていた担当者のメールアドレスにメールで送信しておくといったケース、EDI等のシステム連携で伝達するケース、等があります。
回答受領
Customerは、注文に対する納期の回答を受け取ります。
出荷依頼～出庫完了の伝達まで
さて、在庫の引き当てが終わり、納期回答まで行いました。あとは出荷依頼を行い、実際に注文を受けた品物を出庫していくことになります。
出荷依頼
在庫の引き当ても終わっているので、営業さんは出荷の依頼を行います。出荷のタイミングはCustomerとの調整をしたうえで、いつ届けてほしいのか、という点を協議して決定していきます。
仮に、自社として特定の曜日に出荷のタイミングを合わせている、などのオペレーションを行っている場合は、こうしたオペレーション上の都合も考慮して出荷の依頼をかけていくことになります。
出荷伝票作成
出荷の依頼を受けたら、出荷する日までの準備をするための計画作成のためにも出荷伝票を作成します。これが、出荷をこれから行っていくという活動のトリガーになります。
出荷伝票は、OBD：Outbound Deliveryとも言います。
ピッキング、パッキング
出荷伝票が作成されたら、その伝票上に記載されている実際に作業を行う必要のあるタイミングに合わせて、ピッキング、パッキングを行います。
ピッキングとは、在庫として棚に保管されている状態の品物を取り出す、あるいはその辺に平積みされている品物を持ち出すことで、パッキングとは、取り出した品物をプチプチやビニール袋、あるいは段ボールなどで梱包し、出荷できる状態に整えることを指します。
ものによってはピッキングやパッキングにも工数がかかるので、どうやってピッキング、パッキングしていけば最も効率よく作業が出来るのか、という点を整理したうえで最適なピッキングの経路やパッキングの順序を決める、という工夫をしている企業もあります。
出庫
出荷できる状態にしたら、トラックに積み、Customerの希望納品住所に向けて発送します。倉庫から出すことになるので、これを出庫（GI：Goods Issue）と言います。
出庫完了の伝達
出庫を終えたら、営業さんに出庫完了の伝達を行います。
物品の受領
Customerは、出庫された品物を受領します。
請求書作成～入金消込
ここまでで、Customerが品物を受領してくれました。あとは、請求書を作成し、Customerから入金を受けるプロセスとなります。
請求書作成、送付
出庫が完了しましたので、営業さんは請求書を作成し、Customerに対して送付します。請求書は、Billing Documentと表現したり、Customer IV：Customer Invoiceと表現することがあります。
倉庫から出庫が行われたら、その瞬間に請求書が自動で出来上がるようにシステムを整備している企業もいます。
送付完了の伝達
請求書をCustomerに送ったら、それを会計の担当者に連絡します。こうすることで、売り上げを計上してもらいます。送付の方法は、メール添付、EDI連携、等があります。
請求書の転記
会計の担当者は、営業さんから連絡を受けた請求書を頂くことで、売上を計上します。
企業によっては、出庫が行われた時点で請求書を自動作成し、そしてまた請求書の作成と同時に売上計上をする、という仕組みにしている企業もあります。
在庫販売のケースだと、こうした自動化をしているケースが大半かと思われますが、サービスの提供なんかですと、売り上げとして認識できるかどうかがCustomerがサービスを受け入れてくれたかどうかに依存する部分もあるので、自動化できないシナリオもあります。
請求書の受領
Customerは請求書を受領します。この中身をチェックして、請求されているものが実際に届いているかどうかを確認し、問題が無ければ後続のプロセスに移ります。
支払いの実施
請求書の内容に問題が無ければ、Customerは支払いを実施してくれます。
請求書には、振込先や支払い期日などの情報が記載されているので、それにしたがってCustomerは支払いをしてくれます。もし、期日になっても支払いが確認できなかった場合、営業さんからフォローアップを行うこととなります。
入金確認、伝達
入金がされたら、預金口座にアクセスできる財務部門がその確認を行います。毎日チェックするわけにはいかないので、月末などにまとめて確認し、その結果入金があったものは会計部門に連絡をすることとなります。
入金消込
会計部門は、入金があった連絡を受けたら、計上していた売上債権の消込を行います。以上で、在庫販売のシナリオは完了となります。
終わりに
在庫管理品のプロセスフローをまとめてみました。この他にもいくつかプロセスフローをまとめておりますので、ご興味のある方はまとめ記事からご確認をお願いします。