こちらの投稿では、システム導入、特にSAPなどのERP導入にかかわることになった新人コンサルタントさん向けに購買管理とはなんぞや？という解説を行っていきます。
始めに概念のお話をして、あとは業務フロー、そして項目や論点の話などもしていきたいと思います。
今はスタートアップでSaaS導入をしておりSAP導入はしていませんが、個人的にはSAPは大好きですし、いずれまたかかわることもあるだろうなと思っているので、自分の知識の整理のためでもあります。
SAPの話が出てはきますが、購買管理の話がメインになりますので、そちらを確認されたい方にも読んで頂いて損はないと思います。
まずはじめに、私の購買管理に関する経歴を書きます。
そんなに長くはないですが、一応実績はあるととらえて頂ければと思います。
(2021/09 追記：SCＭ関連の投稿をまとめ直しました)
SCＭ関連の投稿をまとめ直しました。ご興味ありましたら、此方の記事をご覧ください。購買管理の概要に加え、シナリオ別のプロセスフローを記載しております。
Agenda
私の購買管理(MM: Material Management)への関与歴
要件定義、Config、設計図書作成、テスト実施
- 重工業における予備部品事業立ち上げプロジェクト：2年
- 資材購買、業務委託、需要予測の領域でMMに関与
- 設計図書作成
- 単体テスト実施
- 統合テスト実施
- 資材購買、業務委託、需要予測の領域でMMに関与
- 自動車製造・販売企業における物流改革プロジェクト：1年
- 予備部品購買、在庫計画の領域でMMに関与
- 要件定義ワークショップ実施
- 要件一覧の作成
- 設計図書作成
- 単体テスト実施
- 予備部品購買、在庫計画の領域でMMに関与
今後の投稿
今回は、ざっくりとした業務フローの説明にとどめますが、今後はシナリオ別の詳細のフローまで、各Actionレベルまで記載していこうと思っています。
- 購買管理とは？
- ものを買う行為を管理すること
- 目的は効率化、可視化、統制
- ざっくり業務フロー：要求、発注、入荷指示、受領、請求書照合
- マスターデータとトランザクションデータ
- Material Master、Vendor Master、Purchase Information Record、Source List
- Purchase Requisition、Purchase Order、Inbound Delivery、Goods Receipt、Invoice
- 登場人物をきちんと把握しましょう
- スイムレーンを使ってAction Ownerを表現
購買管理とは？
ものを買うことを管理すること
購買管理とは、何でしょうか。
言葉の通り、企業の購買活動を管理する業務です。
購買というのは、ものを買う行為です。
ものを買うという行為を、初めから終わりまで管理することを購買管理といいます。
企業によって、さまざまにシナリオがありますが、以下のようなものが購買管理の対象となる、購買活動です。
- 商社が販売を行うための商品を買う
- 自動車の製造会社が、自動車を作るための部品を買う
- ベンチャー企業がオフィスで使うために、 おしゃれな椅子を買う
- コンサルティングファームが、ブレストに使うための高級ノートを買う
- WEB企業が自社サービス提供のためにサーバーを買う
- IT企業がフリーランスのシステム導入サービスを買う
サービスを利用するという行為も、サービスを買っていることになりますので、購買活動となります。
外注と言ったり、業務委託と呼ばれるものも同様で、購買活動になります。
目的は効率化、可視化、統制
なぜ購買管理をする必要があるのか、と言いますと、それは購買行為を効率化し、購買状況を可視化することで、企業内で統制（ガバナンス）をかけるためです。
まず、なにかを買いたい！
となったときに、あらかじめ決まった手順がないとあまりに非効率ですよね。
誰がどこの誰に対して連絡するのかとかをなにかを買いたいと思ったときに毎回やるのは疲れます。
購買管理がきちんとされていると、そもそも誰が発注を出すのか、入庫するのか、ということが決まっていますので、
買いたい！と思った人はその要求を出すだけでいったんOKです。
また、購買管理がきちんとされると、今どこまで購買活動が進んでいるのかがわかります。
買いたいという要望があったものの、部門長がNGを出してとん挫しているのか、それともすでに発注済みで入荷待ちなのか、実は倉庫に来ていました、とか、
こういった情報が可視化されるのです。
最終的には、いつお金を払う必要が出てくるのか、その金額は、という情報も可視化されます。
加えて、購買管理をすることは統制の点でも重要です。
購買管理がきちんとされていない状態ですと、Aさんが自宅宛てに高性能パソコンを納品し、それを会社のお金で払い、データはどこにも残らない、
という非常に悪い状況が発生する可能性があります。
こんな会社があると、経営層がきちんと統制をかけていないことに責任を取ることになり、投資家からも資金を引き上げられる可能性もあります。
企業の活動を効率化、可視化し、そして関係各社のためにも統制をかけることが、購買管理の目的なのです。
ざっくり業務フロー：
要求、発注、入荷指示、受領、請求書照合
以下の図をご覧ください。
非常にざっくりとした説明ですが、購買管理はこのフローになります。
詳細にみていくと各企業で差異が生まれますが、大きな視点で見るとこの流れになるのはどこの企業でも同じです。
別の投稿では、詳細なフローについても記載していく予定です。
PR：Purchase Requisition、購買要求
まず、第一ステップとして、ものを買いたい！という要求が出されるステップです。
購買要求と呼ばれるドキュメント、伝票、申請書の位置づけのファイルを作成されます。
誰が、何をいくつ、いつほしいと言っていた、という情報が後で見返してもわかるようにするためですね。
統制の関係上、いきなり発注して、いきなり買うということはしません。
きちんと統制をかけるためには、ものを使う人と買うという行為をする人を分けます。そのため、購買要求と、購買発注が別のステップになります。
PO：Purchase Order、購買発注
購買要求が出され、それを買ってもOKと判断がされていれば、購買発注を行います。
購買要求は社内だけの話でしたが、購買発注となると、社外に正式に買いたい！という連絡がされることになります。
ここでは、発注書、あるいは契約書が作成され、発注先に送られます。
価格などは事前に見積もりを取っておくか、すでに2019年の間は100円で売ります、などの包括契約などがある場合はその価格となります。
発注においては支払い条件や引き渡し条件などを決めますが、それについては今後の詳細の解説で行います。
IBD：Inbound Delivery、入荷指示（入荷連絡）
購買発注を行った後、発注先から準備できたので送りますねー、と連絡があったら、入荷指示を行います。
例として、車の部品などを買ったときは、それがトラックに乗って今運ばれています、という連絡をうけたと思ってください。
企業内では、その連絡に従って、そろそろ来るかもしれない、という連絡を関係者にしておかないといけません。
車の部品を受け取るのは本社ではなく、倉庫の人たちあるいは工場の人たちになるので、その人たちに連絡をして、準備しておいてもらうことが目的です。
ここで作るファイルが、入荷指示と呼ばれるものです。
なお、サービスを購入しているときは入荷指示を作らないようにしている企業であれば、このステップはスキップされます。
GR：Goods Receipt、受領
実際にモノが届いて、受け取った、というのがこのステップです。
受領を行った証として、受領書を作成します。
このあと、受け取ったものがきちんと動くのか、注文していたものと同じ数量化、同じ型番か、などをチェックします。
チェックの結果、問題がないことを確認出来たら、買掛金などの債務を認識します。
サービスを購入している場合は、サービスが始まって、要望通りに動いていることが確認できるか、あるいはシステム導入などであれば
システム導入が成功に終わった場合に受領書を作成し、債務を認識します。
実体のあるものではないですが、受領書の作成は必要となるわけです。
IV：Inovice Verification、請求書照合
ものを受け取った後、発注先は企業に対して請求書を送ってきます。
請求書を受け取ったら、金額があっているのか、請求されている内容と受領したものが一致しているか、確認を行います。
これが請求書照合となります。
一致していれば、請求内容は正しいので、支払い条件に従って入金を行うステップにつながっていきます。
ここでは、請求書照合を行った結果をシステムに残すこととなります。
マスターデータとトランザクションデータ
次に、先ほどのざっくり説明したフローをシステムの目線で見てみましょう。
以下にマスターデータとトランザクションデータに分けてフローを記載しています。
システム内のデータは、マスターデータとトランザクションデータに分かれます。
トランザクションデータというのは、取引などの活動に伴い都度都度発生するデータです。
一方、マスターデータはトランザクションデータに記載される情報の元データとなります。
例えば、車の部品を買うとき、型番a001、名前はwiper、重さは...という情報を毎回入力するのは手間ですよね。
こういう時にマスターデータとして、型番a001、名前はwiper、重さは...という情報をあらかじめ登録しておきますと、
トランザクションデータを作るときに型番a001を入力するだけで他の情報を引っ張れるようになります。
こんな使い方をするのが、マスターデータとトランザクションデータの関係です。
矢印の流れで、データの流れを示しています。
それでは、以下にて各マスターとトランザクションデータの役割を見ていきましょう。
Material Master、マテリアルマスター、品目マスター
マテリアルマスターは、購買する対象の情報が入っているマスターとなります。
先ほどの例でも記載した通り、買う対象、品目、マテリアルと言ったりしますが、これらの基本情報が格納されており、
トランザクションデータであるPRが作成された時に型番の入力だけで他の情報を引き出せるようにしてくれています。
厳密には販売の時にも使うので、社内で使用するもの、品目、マテリアルであれば登録しています。
サービスを買うときは、サービスとして品目を登録しておきます。
基本的には、品目が事前に品目マスターに登録されていなければ購買要求を作るということはできません。
Vendor Master、ベンダーマスター、仕入先マスター
ベンダーマスターは、発注先の情報を扱うマスターです。
購買要求を作成するときはまだどこに発注するのが決めていませんが、購買発注のトランザクションデータを作成するときには発注先の情報が必要となります。
ベンダーマスターには、発注先の企業の名前、支払い条件、引き渡し条件、発注書の送付先住所などの情報が格納されています。
PIR：Purchase Information Record、購買情報レコード
PIRには、マテリアル × ベンダーの組み合わせで、このマテリアルを、このベンダーから買うとき、に関係する情報が格納されています。
例えば、価格、発注数量(一度の発注で何個以上にしないといけない、という取り決めのある数量)、数量違いの上限(いくらまで不足、あるいは多くてもOKとするか)などです。
ちなみに、引き渡し条件や支払い条件など、一部ベンダーマスターがすでに持っている情報と重複するものもあります。
これら、情報の重複があった場合は、PIRの情報が優先されます。
例えば、ベンダーXは基本的には引き渡し条件はFOB: Free on Board (ベンダーが荷積みするまでやってくれる)というルールなのですが、
マテリアルM001を買うときに限ってはEXW: Ex Works (発注者がベンダーのところまで取りに来る)という決まりになっているときなどは、
ベンダーマスターにほFOBを入れておき、PIRにはEXWを入れておく、という運用になります。
Source List、ソースリスト、供給元一覧
ソースリストでは、このマテリアルはどのベンダー達から買えるのか、買うことを企業として許しているのか、という情報を管理しています。
発注を行うときですが、マテリアルM001は常にベンダーXから買う、と決めているのではなく、
常に2社以上から見積もりを取って比較して、安いほうにしている、というときはこの2社がソースリストに入っていないといけません。
また、このソースリストに入っていないベンダーからは買えないようにする、つまり購買発注のデータを作れないようにする制御もしてくれます。
Purchase Requisition、購買要求
業務フローのざっくり説明のところでも出てきましたが、PRは購買要求のデータです。
買いたい人が作るデータなので、ここでは
いつ、何が、何個、どこに欲しいか、という情報を入力します。
使うことを目的にしていてどこから買うかはどうでもいい、というときは発注先の情報は不要なので、
マテリアルマスターの情報だけで作成可能なデータになります。
サービスを買うときなんかは、どこから買うサービスか、というものが重要になりますので、
どこから買いたい、というベンダーの情報も一緒にPRに入れることもあります。
Purchase Order、購買発注
POは、外部に出すことになるデータです。
PRの情報を基本として、どこに発注するのか、という情報と契約関係の情報を、入力することになります。
したがって、PR、ベンダーマスター、PIR、ソースリストを元ネタとして、POは作成されます。
発注のタイミングで、マテリアルM001と同じ用途で使えるM002の方が安いしすぐに届く、となればPRとは違うものを
POに入れる、そして納期を、前倒しにする、と言った変更も行われます。
Inbound Delivery、入荷指示
IBDは、ものがいつ届く、という情報を持ったデータになります。
PR, POには発注元の希望納期がありましたが、POを提出したあとでベンダーから、この日に届けます、
あるいは出荷したのであと数日で届きます、という連絡があった時に作るデータです。
POに書いてある通りの情報をコピーして作られるのですが、仮に希望納期よりも遅い日付になるのであればその日を入力します。
さらには10個頼んでいたものが7個、3個と2回に分けて届くことになった場合はIBDを2つ作り、それぞれに数量と納品の日付を入れます。
こうして作られたIBDをもとに、倉庫や工場では入荷の準備がされます。
入荷の準備というのが何かと言うと、人の配置です。
製造業なんかでは毎日大量にものを買っていますが、このIBDに記載されている日付と数量を見て、たくさんものが届く日と、そうでない日を識別し、
人の配置を変える、というオペレーションがよく行われています。
Goods Receipt、受領書
GRは、Goods Receivingであれば受領する、という行為のことを言い、Goods Receiptであれば受領書のことを指します。
文脈によって受領するという行為のことを言っていたり、受領書のことを言っていたりしますので注意です。
GRは、ものが届いた時、あるいはサービスの提供を受けた時に作るデータです。
IBDのデータをもとに作り、実際に届いた日、数量、などを入力します。
GR後のものに対してチェックが終わり、問題ないことが確認されると、在庫が計上され、販売したり、製造のために消費できるようになります。
同時に、買掛け金などの債務が計上されます。どんな勘定科目を使うのか、という情報は、マテリアルマスターの項目で自動で決定されます。
Invoice、請求書
請求書は、ベンダーから送られてくるものになります。
この請求書の情報を、管理のためシステム内にも入れます。
入力した情報がPO、GRの情報と乖離がないかを確認する行為が Invoice Verification 請求書照合となります。
完全に合致すれば、支払いが後続プロセスとなりますので、支払い依頼をすることになります。
登場人物をきちんと把握しましょう
さて、ここまでで、簡単に購買管理の業務フローを説明しました。
概要としての説明だったので、今回はアクションと作るデータのつながりをシンプルに説明していましたが、
コンサルタントとしては誰がその行為に責任を持つのか、という登場人物を押さえておく必要があります。
購買管理といっても、関わる部署、部門の人々は多いので、基本的にはその部署、部門の人々がシステム導入において決定権を持ちます。
POドキュメントタイプはどんなものに設定しましょうか？という質問を製造部門や、経理部門に聞いても意味がないわけです。
そこで、業務フローは、登場人物と一緒に抑えるために、スイムレーンというものを作ります。
スイムレーンを使ってAction Ownerを表現
コンサルタントとしては、スイムレーンが命だと考えています。
見たらわかる通りですが、スイムレーンというのは、水泳で使うレーンのような表現から来ています。
これはどんなプロジェクトでも作りますし、これをもとにシステム設計が行われます。
詳細の説明は次回以降としますが、業務フローといったら、スイムレーンのことであると捉えたほうがいいでしょう。
スイムレーンは内部監査の時にも使われたり、上場を狙う会社であれば
社内の統制が取れていることの証明に使われるものでもあるので、非常に重要です。
今、私はスタートアップでシステム導入していますが、まさにこのスイムレーンを作成するところから始めています。
今回はここまでとさせて頂きます。SAPの話は少し抑えめでしたが、次回からはSAPによりフォーカスを当てた内容になるかと思います。