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

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

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

本投稿の想定読者

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

期待できるメリット

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

サービス、外注購買とは

まず初めにおさらいです。サービス、外注購買とは何でしょうか。

内容としては、物品を受け取るケースではなく、特定のサービスなどを受ける、あるいは自社で実施する作業の一部を外部に委託する外注などを指します。

例えば、コンサルティングサービスを受ける、ソフトウェアライセンスを購入する、製造という本来は自社で行う活動を他社に委託する（外注する）、といったケースがあります。

本投稿では、そんなサービス、外注購買について、取り扱います。

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

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

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

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

購買要求の作成

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

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

ある程度の統制を必要とする中小企業、大企業であれば購買要求はシステムに情報を登録することにしているケースが一般的となります。特に、サービス、外注となると、物品が存在しないため、ソフトウェアライセンスのようなケースを除きカタログのような情報もなく、依頼内容を個別に定義していくことが多いので、何を購入したいと思っているのか、という点はきっちりと情報として残していく必要があります。

物品があるケースとは違い、数週間や数カ月の期間にわたるサービスを受ける場合もありますし、それに伴って支払いは毎月発生するようなケースもあります。

こうした基本情報をきちんと購買要求の時点でまとめておくことが重要となります。

注意：大規模プロジェクトの発注などは非常に高価になる

サービス、外注の発注というのは、場合によってはものすごく高価なものになるケースがあります。

プラントエンジニアリング会社に大規模設備の建築を依頼する場合や、飛行機や鉄道などの製造を依頼するケース、大規模なシステム導入プロジェクトにおいては、数十億円単位で発注がされることがあります。

こうしたケースにおいては、やはり統制の観点からも購買要求を出す部門と発注をする部門は明確に分けておくべきという考えがありますので、こうしたケースでは要求部門が発注を出すのではなく、購買部門が発注を行うことが一般的です。

購買要求の承認

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

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

サービス、外注購買の場合は、物品が伴わないということもあり何を購買しようとしているのかをきちんと見る必要がある、ということで、金額が小額のモノであっても承認をスキップすることは少ない認識でいます。

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

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

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

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

金額としても大きなものになってくる場合は、企業の統制の観点でもSupplierをはじめから決めておくのではなく、複数の候補を比較検討して最終決定する必要性が出てきます。この場合、購買要求時点ではどんなサービスや外注業務を発注してもらいたいのか、という情報と候補であるSupplierさんが数社程度決まっている状況になります。

よって、どのSupplierさんに対して実際に発注するのか、という部分が明確にされていないので、購買部門がどのSupplierさんから購入するのかを最終決定してあげて、購買発注を作成するわけですね。

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

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

購買発注の作成

購買部門が承認された購買要求をもとに、購買発注を作成します。

入札をさせているケースなどの場合、何を発注しようとしているのかをきちんと購買部門が把握した状態になるので、この段階で要求部門に確認のために手戻りが発生する、ということは基本的にありません。

購買発注の承認

購買発注は企業から外部に対しての正式な発注書、注文書を作成するステップとなりますので、統制の観点から承認が必要になります。

購買部門としては初めて承認を行うことになり、また発注内容が大規模プロジェクトになっている場合は契約内容のうち、支払い条件、引き渡し条件、期日と品質の考え方、仮に品質が規定したものに達しなかった場合などの条項を確認することとなります。

ソフトウェアライセンスなどが対象である場合は金額が小さいということもあり、そこまで細かな確認はされませんが、いずれにせよ承認行為は実施されることとなります。

発注書の送付

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

ソフトウェアライセンスの場合は提供するSupplierさんがカタログを用意していて、オンラインのポータルから発注できるケースも増えてきており、オンラインで発注ができるようになってきています。

しかし、Supplierさんがある程度の期間を要するサービス、外注業務などを提供してくれる場合は、その業務のスコープ、実施内容、スケジュールなどをSupplierさんとの協議のうえで綿密に定義し、こうした情報をきちんと合意したうえで、それらの情報を別添の情報として、発注を行うということになります。

サービスの提供開始～請求書の送付まで

発注書の送付が終わりましたので、次はサービスの提供を受けるところから、請求書の送付までです。

サービスの提供開始

Supplierさんは、発注書を受領したら、注文を受けたソフトウェアライセンス、あるいはあらかじめスコープ等を合意したサービスの提供を開始します。

ソフトウェアライセンスなどの場合はオンラインで即時に利用可能になるケースや、ちょっとした導入手順が必要になるケースも存在します。

サービス受領

Supplierさんがサービスを提供したら、次に要求部門がそれを確認することになります。

ここでは一言でサービス受領と書いていますが、長期間にわたって提供されるサービスの場合は事前に合意した期日までに期待されていた品質通りのサービスが提供されたかどうかをもって判断を行い、きちんとサービスが受領されたかどうかを判断します。

物品がある場合は検品というプロセスが物品の受領後に存在していましたが、ここでは検品の代わりに研修という言葉を使用します。仮に、事前に合意していた品質に達していない、期日は訪れたものの作成することとになっていたレポートが出来上がっていない、などの理由で検収がされないとしたら、検収がされるまでは無償でSupplierさんからサービスの提供が継続される、などのパターンがあります。

しかしながら、こうした仮に期日に作業が完了しなった場合はどうするか、という点は発注書の作成の前段階で前提事項として明確にしておくことになり、そちらで定義された方法に従って発注側とSupplier側で対応を合意することとなります。

ソフトウェアラインセンスが提供されている場合は、そのソフトウェアが提供されて、問題なく動くことが確認できたならばあとは事前に決めておいたスケジュールに沿って月次や年次などで請求がされるので、そこまで厳密に品質がどうだったとかのチェックは行うことはありません。

受領書作成

品質も問題なくサービスや外注業務が提供された場合は、発注側が受領書を作成し、Supplierさんに渡すこととなります。

物品が存在する場合はそれらを運ぶ物流業者さんが発注側のサインがされた納品書等を受け取るというステップがありましたが、サービス、外注購買の場合はSupplierが直接発注者である企業とやり取りをすることになるので、受領書は発注者の企業から直接Supplierに渡されます。

ソフトウェアライセンスの場合はライセンスの提供後、特にSupplierとしてはサインされた受領書などを必要とするケースはなくなっているのが一般的ですが、サービスの提供、外注業務を提供するSupplierとしては、紙面で顧客である発注担当者からサインを頂くというプロセスが今も残っています。

入庫連絡

サービス、外注ではありますが、きちんとSupplierさんから提供された場合には入庫の連絡を要求部門から購買部門に対して伝える必要があります。

入庫というとやはり倉庫で受け取り、棚に入れる様子をイメージされる方が多いとは思いますが、ここではサービス、外注業務の受領をしたこと、と捉えてください。製造業なんかだと、実態の存在しないものであっても受け取った際には入庫、と表現するケースがあります。

入庫確認

購買部門は発注したものがきちんと要求部門に提供されたことを確認します。

請求書の作成

Supplierさんは、注文先に対してソフトウェアラインセンス、サービス、あるいは外注業務を提供し終えたので、その後、請求書の作成を行います。

請求書の送付

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

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

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

請求書の受領

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

請求書照合

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

このケースでは購買部門がサービス、外注の発注をしていますが、購買部門の方というのは日々いろいろな発注ぎょむを行っていますので、請求書を受け取ってもどれに対する請求なのか、簡単にはわかりません。そこで、付属している注文書、発注書の番号を手掛かりにして、発注したときの情報を検索し、その情報と請求書の情報を比較します。これを請求書照合と言います。

請求書照合としては、注文書の金額と請求書上の内容があっているかを照合します。