Consulting SAP/IT

【コンサル】一般購買のプロセスフロー (購買部門が発注するケース + 入札があるケース)【業務視点の購買管理】

本投稿では、現在コンサルで業務プロセス設計およびSAP導入をしている投稿者が、購買管理における一般購買のプロセスフローを解説しております。

この他にも購買管理関連の投稿はこちらにまとめがあります。また、購買管理に限らずSCM関連の記事はこちらのSCM関連記事まとめをご覧になってください。

本投稿の想定読者

  • SAP導入プロジェクトで購買管理領域を担当されるコンサルタント、システム部門の方
  • SCM領域のうち、特に購買管理領域について知りたい方

期待できるメリット

  • 購買管理領域における業務プロセスがわかる
  • 購買管理領域のプロセスフローのサンプルが見れる

一般購買とは

まず初めにおさらいです。一般購買とは何でしょうか。

一般購買、間接購買、消耗品購買、と企業によってさまざまな呼び方があるのですが、内容としては、主たる事業に関連しない、購買のことです。

例えば、製造業であれば、製造を行う上で扱う原材料や部品ではなく、営業さんが使用するPC、総務部門が用意するノートや筆記用具などの購買を指します。これらは製造そのものに関連していないので、主たる事業に関連しないものであると判断できます。

本投稿では、そんな一般購買について、取り扱います。

なお、一般購買は、購買部門が発注をするケースと、要求部門が発注をするケースの2つがあります。経験的には、どちらも半々なので、どちらのプロセスフローも作成しました。本投稿では、一般購買のプロセスフローのうち、購買部門が発注を行うケースを取り扱っています。

購買要求の作成~発注書の送付まで

各プロセスフロー内のタスクについて、以下詳述しております。なお、製造業をイメージしながらプロセスフローを作っています。

まずは購買要求の作成から、発注書の送付までを見ていきましょう

購買要求の作成

最初のステップは購買要求の作成です。購買要求を作成する部門として、このプロセスフローでは、営業、人事、総務など、としています。一般購買は、どの部門が要求を出すこともあり得ます。

また、総じて、購買要求を作成した部門のことを、要求部門と言います。実際に要求部門という部門が存在するということを意味しているわけではなく、あくまで、購買要求を出した部門のことを要求部門と呼ぶ、という点にはご注意ください。

ある程度の統制を必要とする中小企業、大企業であれば購買要求はシステムに情報を登録することにしているケースが一般的なのですが、一般購買の場合はそうした企業であってもメールを一本書く程度の扱いで済ませているケースもあります。

注意:一般購買と言っても必ずしも安価なものばかりではない

ここまでのご説明で、一般購買というと主たる事業に関連しないものだから、そんなに高価なものではない、価格の小さいものばかりが対象になるのだな、と思われるかもしれませんが、企業によってはとんでもなく高価なものを対象とした一般購買も存在します。

例えば、製造業の企業が自社でデータセンターを保有していて、設計業務や製品の流体力学的なシミュレーション等を行うことを目的にオンプレミスのシステムを持っている場合などは、20億円などの巨額な費用をサーバー、つまり大型コンピューターに投下している場合が存在します。

こうしたサーバーは、製造業にとっては製造時に消費される部品ではないので在庫ではなく、かといって不動産でもないので、一応一般購買という扱いとなります。ただし、金額が非常に大きくなるため、こうした購買においては、いきなり購買要求から開始するのではなく、事前に企画書の作成、稟議の実行、予算枠の取得などが前年度末や今期の開始時点で行わることとなります。

購買要求の承認

購買要求が作成されたら、その要求がもっともなものなのかを要求を作成した部門の中で確認します。問題が無ければ、承認を行い、次のステップに移ります。

承認されない場合は購買をあきらめるか、予算が準備できたときにもう一度購買する、などが考えられます。メール一本で購買要求を出している場合は、メールの文面に記載している購買の理由や正当性についての記述が詳細ではないので書き直してください、という意味合いで承認が下りない、というケースもありますので、そうした場合はもう一度メールを書き直す、ということをすることとなります。

一般購買は、ものによって、あるいは職階によって金額が明確に制限されていることが一般的です。例えば、平社員の方が新しいマウスやキーボードなどを購入したいときは5,000円までは直属の上司が承認すればOKであるものの、それを超える場合は部長の承認が必要となる、といったケースがよくあります。

購買発注の作成

購買要求が承認されると、次は実際に購入をしてくれる購買部門へ情報の伝達をすることとなります。一般購買では、購買発注の作成を購買部門ではなく要求部門が行うケースもあるのですが、ここで紹介するプロセスフローは購買部門が購買発注を作成するケースとなっています。

なお、一般購買の場合は総務部門が購買発注の作成を担当するというルールにしている企業もありますので、その場合はこちらでご紹介しているプロセスフローの購買部門の行を総務部門に置き替えて確認をして頂ければと思います。

大規模な企業になると、購買活動を専門的に実施してくれる購買部門というものがあります。ここでは大規模製造業をイメージし、購買部門を登場させました。

承認された購買要求を購買部門が受け取り、購買発注を作成します。基本は購買要求として情報が整っていれば、何も問題なく購買発注を作成できるのですが、購買要求だけでは情報が不十分、あるいは要求部門も決め切れていないといったときは購買部門が要求部門と確認をしながら、必要な項目を埋めることとなります。

入札させる場合は購買発注の作成前

先に記載した、一般購買ではあるものの非常に高価なものの購入、例えば大規模サーバーの購入などでは、この購買発注を作成するまえに購買部門が候補であるSupplierに入札をさせるといったケースが存在します。

金額としても大きなものになってくる場合は、企業の統制の観点でもSupplierをはじめから決めておくのではなく、複数の候補を比較検討して最終決定する必要性が出てきます。この場合、購買要求時点では何をいつ買いたいのか、という情報だけが決まっており、どのSupplierさんから購入するのか、という部分が明確にされていません。そこで、購買部門がどのSupplierさんから購入するのかを最終決定してあげて、購買発注を作成するわけですね。

プロセスフロー上では購買発注の作成、と一つのステップにしていますが、実際には購買部門から各Supplierへ要求事項の伝達、提案の受領、提案内容の比較検討、Supplierの決定、決定内容とその理由について報告書にまとめる、といったことをここで実施することとなります。

こうした購買活動は年に数回程度しか実施されませんが、この期間は購買部門の方は大忙しになります。

購買発注の承認

購買発注は企業から外部に対しての正式な発注書、注文書を作成するステップとなりますので、統制の観点から承認が必要になります。これも金額によっては承認をスキップする、というケースも企業によってはありますが、こうしたルールは購買管理規定によって定義されることとなります。

発注書の送付

必要な承認も終わったら、正式にSupplierさんに購買発注を行うことになります。ここではSupplierさんに提出する発注書を作成し、送付することとなります。

発注書は紙面で作成することもまだまだ一般的ですが、最近はオンラインで必要事項を入力してもらうことで発注書とみなすケースも多くなってきました。ただし、オンラインで注文している場合においても、PDF形式で発注した内容を出力しておくなどすることで、発注の内容を記録しておくことは必要となります。

eCommerceなんかだと、ポータルから発注した内容をPDFにそのまま発注書として出力できるようにしてくれていることが多いですね。

出荷連絡の受領~物品の受領まで

発注書の送付が終わりましたので、次は出荷連絡の受領から、物品の受領までです。

出荷

Supplierさんは、発注書を受領したら、注文を受けた物品を出荷してくれます。

出荷の連絡

Supplierさんが物品を出荷したら、しばらくはトラック等で輸送中になります。しかしながら、出荷自体は行ったことを伝えるため、ここで出荷の連絡を注文してくれた企業に対して行います。

出荷の際に、自社の物流業者ではなく他社の物流業者を利用している場合は物品につけられた問い合わせ番号や追跡番号などを合わせて連絡し、いつ頃届きそうか、といった情報を伝達することとなります。

ここで取り扱っているものは一般購買品ですが、重要度に応じて出荷連絡があったりなかったり、簡易的なものだったりします。いわゆる消耗品であれば簡易的な出荷連絡か、連絡そのものが無かったりしますが、高額なものであれば追跡番号もきちんと合わせた出荷連絡になります。

出荷連絡の受領

Supplierさんから出荷連絡の受領をします。電話や、メール、最近は減りましたがFAXも方法としては存在します。

Supplierさんとの間でよく購買が行われる場合は、EDIといったシステム連携をしておくこともあります。その場合、Supplierさんが出荷の連絡をEDIを通じて注文者に対して伝達することが出来ます。

出荷連絡の伝達

Supplierさんから出荷連絡を受けたら、一般購買の場合は要求部門がそのまま物品を受け取ることが多いため、購買部門は要求部門にその伝達をします。

非常に高価だったり、サイズやボリュームが大きなものの場合は受け取るときにきちんと要求部門の方が立ち会うことも必要になってくるため、以降はSupplierさんと要求部門の担当者間でやり取りを行い、物品の受領に備えることとなります。

製造業において、在庫管理品を受け取る場合などは自社製造拠点や倉庫で受け取ることになるため、入荷指示を作成していましたが、一般購買では入荷指示を作成しないこととなります。

物品の受領

Supplierさんが出荷したものをここで受け取ることとなります。

Supplierさんから納品された物品には、納品書が添付されています。これは、Supplierさんにとって確かに納品しました、という証明となる文書なのですが、 ここに物品の受領を行ったというサインを行うこととなります。

サインされた納品書は、物品を運んでくれた業者さんがSupplierさんに返送することとなります。

検品、入庫~入庫伝達まで

物品の受領をしましたので、次は検品から、入庫の伝達までです。

検品

受け取ったものが注文しているものと合致しているか、品質に問題がないかを確認するステップを検品と言います。

この検品というプロセスですが、一般購買のうち、消耗品などの購入の場合は非常に簡便なステップとなります。まずは外観を見て、明らかな異常がないかなどの確認で完了します。あるいは、物流業者さんが届けたらそのまま去っていくというケースもあるので、実態として検品していないケースもあります。

しかしながら、ここも非常に高額なものであった場合は別で、サーバーなどの精密機械を購入している場合は数量などもきちんとカウントし、品質も確認します。

入庫、受領書作成

検品の完了した物品を入庫します。

入庫というと倉庫に搬入し、棚に入れることを想像されるかと思いますが、ここでは一般購買なので、消耗品などの場合は受け取り、受領書を作成するというステップを指していて、倉庫に入れるという行為は伴わないこともあります。

既にSupplierさん向けには納品書へのサインを行っていますが、社内的にもきちんと受領したという証明として受領書を作成します。受領書はSupplierさんが物品に添付していた納品書とセットになっているケースもあります。

なお、高額なものに関しては、在庫管理の対象にはなりませんが、資産管理の対象になるため、資産管理番号等をラベルに出力し、添付するということもしていきます。このあたりは別の在庫管理のプロセスで解説していきます。

入庫連絡

要求部門として注文したものを受け取ったら、つまり、入庫が終わったら、注文されたものが利用可能な状況になっていることを購買部門に連絡します。これによって、購買部門は発注したものがきちんと納品されたということを知ります。

入庫確認

購買部門は、入庫が完了していることの連絡を要求部門から受けます。

請求書の作成

Supplierさんは、注文先に対して物品を引き渡し、納品書へサインをもらった後、請求書の作成を行います。

請求書の送付

作成した請求書は、Supplierさんから郵送、メール、EDI、FAX等を用いて注文先に届けられます。

請求書の受領~支払いの転記まで

さて、入庫まで終わりましたので、あとは請求書を受領し、支払いを行うまでのプロセスを見てみましょう。

請求書の受領

Supplierさんが送付した請求書を受領します。

請求書照合

Supplierさんが送付した請求書には、関連する注文書、発注書の番号が記載されています。その情報を手掛かりにして、請求されている金額と、注文した内容が合致しているか、また受領は既に完了しているのか、という情報を確認します。

請求書照合としては、注文書の金額や受け取る予定の物品の数量と、請求書上の内容があっているかを照合します。

請求書の転送

請求書照合の結果、発注内容と請求内容が合致していれば、請求書の情報を会計部門に転送し、転記を依頼します。

請求書の転記

会計部門は請求書を受領し、買掛債務として転記します。

支払い実行

買掛債務に対しては支払いが必要となります。財務部門が支払いについて承認を行い、支払いが実行されます。

支払いの転記

支払いが実行された場合、その内容を会計部門が転記し、前のステップで記録しておいた買掛債務を消し込みます。

終わりに

一般購買のうち、購買部門が発注を作成するケースのプロセスフローをまとめてみました。この他にもいくつかプロセスフローをまとめておりますので、ご興味のある方はまとめ記事からご確認をお願いします。

-Consulting, SAP/IT

© 2024 Soloblog - ITコンサルのざっくり解説 Powered by AFFINGER5