メールとExcelから脱却する：調達業務をエンドツーエンドで自動化する方法

エンドツーエンドの調達自動化とは

調達業務の一部だけをデジタル化するのではなく、最初から最後まで業務の状態をつなげて管理する考え方です。

企業によって異なりますが、例えば、

1. 購買ニーズ
2. 購買申請
3. 予算・ポリシー確認
4. 承認
5. サプライヤー選定・確認
6. 新規取引先登録
7. 発注
8. 取引先確認
9. 納品・役務完了
10. 検収
11. 請求書
12. 照合・例外処理
13. 経理・ERP連携
14. 可視化・監査

という流れになります。

すべてを完全自動化する必要はありません。

重要なのは、各工程が一つの業務としてつながっていることです。

Fluyentaの現在の製品情報でも、Vendor Onboarding、PO Approvals、Contract Management、業務モニタリング、Vendor SelectionからInvoice・FulfillmentまでのProcurement-to-Deliveryなどを、調達・企業業務向けのユースケースとして紹介しています。

なぜ調達業務はメールとExcelに依存しやすいのか

メールやExcel自体が悪いわけではありません。

柔軟で、誰でも使いやすく、すぐに始められます。

そのため調達業務では、

1. 社員がExcelで申請。
2. 上司がメールで「承認」。
3. 調達が見積を依頼。
4. 比較表をExcelで作成。
5. 新しい取引先からメールで情報を受け取る。
6. 経理から追加資料を依頼。
7. 担当者がERPへ取引先登録。
8. 発注書を作成。
9. 請求書がメールで届く。
10. 納品されたかを別担当者へ確認。
11. 差異があればまたメール。

という形になりやすくなります。

業務量が少ないうちは問題にならないかもしれません。

しかし、案件数、部門、取引先、ルール、システムが増えると、業務の現在地が見えにくくなります。

分断された調達業務では何が見えなくなるのか

例えば管理者が、

• 今何件の申請が止まっているか。
• 誰が承認待ちなのか。
• なぜ否決されたのか。
• 新規サプライヤー登録は完了しているか。
• 承認済み案件からPOが作成されたか。
• 納品確認は終わったか。
• 請求書と注文内容は一致しているか。
• どの例外が繰り返し起きているか。
• 各工程に何日かかっているか。

を確認しにくくなります。

必要な情報は存在している。

しかし、メール、Excel、人、ERP、フォルダに分散している状態です。

業務自動化では、それらを一つのプロセス履歴としてつなぎます。

調達業務を工程ごとに見る

1. 購買申請

最初は「何かを購入したい」というニーズです。

Excelファイルをメールで送る代わりに、構造化された申請フォームを利用できます。

例えば、

• 購入目的、
• 部門・プロジェクト、
• 商品・サービス、
• 概算金額、
• 希望日、
• コストセンター、
• 候補取引先、
• 関連資料

などを入力します。

実際の項目は会社のルールに合わせます。

重要なのは、ExcelをWeb化することだけではありません。

申請に、案件番号、ステータス、担当者が生まれることです。

2. 予算・ポリシー確認

人に回す前に、明確なルールについては自動確認できます。

例えば、

• コストセンターがあるか。
• 必要資料が添付されているか。
• 金額によって追加承認が必要か。
• 取引先は登録済みか。
• 調達部門による確認が必要なカテゴリか。

などです。

固定ルールはAIに判断させる必要はありません。

例えば、一定金額以上 → 追加承認なら、通常のワークフロールールとして処理できます。

3. 承認

金額、部門、案件、カテゴリなどに応じて承認先を切り替えます。

重要なのは、

• 誰が現在の担当者か。
• いつ依頼したか。
• 期限超過していないか。
• 何の情報を見て判断したか。
• 次に何が起こるか。

をワークフローが管理できることです。

Fluyentaの業務自動化機能でも、人によるタスク、業務ルール、分岐、例外などを含むプロセスを設計できます。

4. サプライヤー確認・新規登録

既存の承認済みサプライヤーであれば、そのまま進められます。

新規の場合は、サプライヤー登録を調達業務の一部として開始できます。

例えば外部向けポータルから、

• 会社情報、
• 担当者情報、
• 支払関連情報、
• 契約・同意書、
• 証明書、
• 企業独自の必要資料

などを提出してもらいます。

社内では必要な部門へ自動的に審査を割り当てます。

これは外部向けポータルと直接つながる部分です。

Fluyenta／RunMyProcessの実務例

Fluyenta／RunMyProcessが公開している建材小売企業の匿名事例では、従来、サプライヤー登録をメールや電話で行っていました。

その結果、承認に時間がかかる、透明性が低い、複数拠点で現在の状態が分からない、といった課題がありました。

そこで、構造化された情報収集、承認フロー自動化、進捗可視化を導入し、Fluyentaは登録の迅速化、従業員効率、サプライヤー体験の改善を報告しています。

これはFluyenta／RunMyProcess側の実務経験であり、Axtonの完了案件ではありません。

重要なのは、サプライヤー登録を調達の外にある「別作業」と考えず、購買プロセスの一部として接続できることです。

5. 見積・取引先選定

複数見積が必要な場合もあります。

ワークフローでは、

• 見積依頼、
• 回答管理、
• 必要情報確認、
• 比較、
• 社内審査、
• 選定理由の記録、
• 追加承認

などを整理できます。

ただし、戦略的な調達や交渉をソフトウェアへ丸投げすることが目的ではありません。

取引条件、関係性、品質、リスクなど、人による商務判断が必要な領域があります。

自動化は判断プロセスを支援します。

6. 発注書作成

承認が完了したら、ERPなどへ発注情報を送れます。

例えば、

1. 承認済み購買申請
2. 必要情報確認
3. ERP連携
4. PO作成
5. PO番号をワークフローへ返す

という流れです。

すでに承認された情報を、担当者がもう一度ERPへ入力する必要を減らせます。

FluyentaのSAP向け資料でも、SAPへ到達する前のメール・Excelによる承認や検証を自動化し、承認済み情報をSAPへ連携する考え方を示しています。

7. サプライヤーとのやり取り

発注後もサプライヤーとのやり取りがあります。

• 注文確認。
• 納期回答。
• 追加資料。
• 変更。
• 質問。

こうした情報のうち、業務状態に関係するものはポータル・ワークフローへ記録できます。

一方、通常の会話や交渉はメールや電話を使っても構いません。

目的は、人とのコミュニケーションをなくすことではなく、業務状態をメールだけに依存させないことです。

8. 納品・役務完了確認

請求書が届いたからといって、注文したものが正しく届いたとは限りません。

商品なら、

• 数量、
• 受領日、
• 検品、

などがあります。

サービスなら、

• 役務完了、
• 成果物、
• 担当者確認、

などがあります。

例えば、

1. POあり
2. 納品確認
3. 検収登録
4. 請求書処理可能

という流れです。

建設業の具体的な業務例については、サプライヤー・協力会社・承認業務のガイドをご覧ください。

9. 請求書処理

請求書は、

• メール、
• 外部ポータル、
• デジタルインボイス、
• その他電子チャネル

から受け取る場合があります。

その情報を、

• 取引先、
• PO、
• 納品情報、
• プロジェクト、
• 契約

へ紐づけます。

日本ではデジタル庁がJapan Peppol Authorityとして、Peppolベースの日本向けデジタルインボイス標準仕様JP PINTを管理しています。

デジタルインボイスだけで調達全体が自動化されるわけではありません。

しかし、構造化された請求データをそのまま後工程へ使えることは、手入力中心の処理よりもシステム連携しやすくなります。

10. 照合と例外処理

典型的には、発注内容何を承認したか。

納品・検収実際に何を受け取ったか。

請求書サプライヤーが何を請求しているか。

を比較できます。

例えば、100個発注。

90個受領。

100個分請求。

であれば、例外案件として担当者へ回します。

メールの中で問題を処理するのではなく、例外にも案件番号、担当者、履歴を持たせます。

図1：調達業務を一つにつなぐ

重要なのは、調達は別々のフォームではなく、一つのライフサイクルであるということです。

「エンドツーエンド」が意味しないこと

エンドツーエンドだからといって、

• すべての購買を自動承認する。
• AIがすべての取引先を決める。
• 人間が調達業務からいなくなる。
• チェックなしに支払処理する。
• ERPが不要になる。

という意味ではありません。

エンドツーエンドとは、

• 誰が何をしたか。
• どのルールが適用されたか。
• 何のシステムが更新されたか。
• どんな例外が残っているか。
• 次に何をすべきか。

が業務全体としてつながっている状態です。

手作業中心とオーケストレーションされた調達

各工程の担当者とシステムの役割

担当者を整理するための例です。各企業のポリシーに応じて、役割とシステムを決める必要があります。

調達自動化＝ERPの入れ替えではない

ERPは、

• 取引先、
• 発注、
• 在庫、
• 検収、
• 会計、
• 請求、
• 財務記録

などを適切に管理している場合があります。

問題はERPの外側かもしれません。

例えば現在、

1. 社員
2. Excel申請
3. メール承認
4. 調達確認
5. 経理確認
6. ERPへ手入力

なら、

1. 社員
2. Web申請
3. ワークフロー
4. 承認
5. 内容確認
6. ERP連携

へ変えられます。

ERPはそのまま中心的な取引システムとして残ります。

これは既存システム連携のガイドの「既存システムを残して周辺業務をモダナイズする」という考え方と同じです。

図2：ERPの周囲に調達ワークフローを置く

調達ワークフローは既存システムを置き換えるのではなく、複数システムをまたぐ業務を調整する役割を持ちます。

日本では「受発注のデジタル化」からさらに先へ進める

中小企業庁は、企業間の受発注でFAXや電話が利用されるケースが残っていることを指摘し、電子受発注によって、

• 作業効率、
• 人的ミス、
• 取引履歴検索

などを改善でき、さらに他システムのデータと連携することで追加の生産性向上が期待できると説明しています。

ここが重要です。

FAX → 電子受注だけでも改善です。

しかし、

1. 電子受注データ
2. 調達ワークフロー
3. ERP
4. 納品
5. 請求
6. 分析

までつなぐことで、より大きな価値が生まれます。

デジタルインボイスも一つの工程

デジタル庁は日本のPeppol Authorityとして、JP PINTを管理しています。

これは請求書データを構造化して交換する仕組みです。

しかし、デジタルインボイス＝調達自動化ではありません。

請求書がデジタルでも、

• 購買申請はメール。
• 承認はExcel。
• 取引先登録は手作業。

ということはあり得ます。

大切なのは、それぞれをつなぐことです。

AIは調達業務のどこで役立つのか

AIは、非構造化情報を読む作業で役立つ可能性があります。

例えば、

• 見積書分類、
• 請求書情報抽出、
• 契約・取引先情報の要約、
• 不足情報候補の確認、
• 例外内容の整理、
• 振り分け補助

などです。

例えば、

1. 請求書受信
2. AIが必要項目を抽出
3. 通常ルールで確認
4. 差異検出
5. 経理担当者へ例外内容を表示

という流れです。

ただし、固定ルールをAIで処理する必要はありません。

AI・ルール・人・システムの役割

AIが使えるから使うのではなく、その処理に一番適した仕組みを使うことが重要です。

正常系より「例外」が重要

調達の通常ルートを設計するのは簡単です。

問題は、

• 取引先登録が未完了。
• 予算情報不足。
• 見積期限切れ。
• 一部納品。
• POと価格が違う。
• 請求書に追加料金。
• 承認者不在。
• 検収不可。
• 役務完了について認識が違う。
• ERP連携エラー。

といった例外です。

優れた業務ワークフローでは、

• 誰が対応するか。
• 何を確認するか。
• 誰が例外承認できるか。
• 理由を記録するか。
• 誰へ通知するか。
• いつエスカレーションするか。

を設計します。

図3：例外を含む調達業務

「すべてが完璧に進む図」より、こちらの方が実際の企業業務に近い考え方です。

自動化は管理を弱くすることではない

目的は、承認をなくすことではありません。

考えるべきは、どの承認が本当に必要かです。

• 重複した承認なら削除する。
• 企業ルール上必要なら残す。
• 金額によって追加する。
• 例外時だけ上位承認する。

まず業務を簡素化し、その後で自動化します。

役割分担を明確にする

調達では、例えば、

• 申請者は購買ニーズを出す。
• 承認者は予算・支出を認める。
• 調達は取引先・条件を管理する。
• 現場・利用部門は納品を確認する。
• 経理は請求・支払プロセスを管理する。

というように役割が分かれる場合があります。

実際の責任分担は企業ごとに異なります。

自動化によって、その役割を曖昧にするのではなく、誰が何を判断したかを明確にすることが重要です。

サプライヤー体験も調達品質の一部

サプライヤー側も、

• 何を提出すればよいか。
• 登録が終わったか。
• 修正が必要か。
• POが発行されたか。
• どの番号を請求書へ入れるか。

などを知る必要があります。

不明点が多いほど、調達担当者への問い合わせも増えます。

外部向けポータルによって、必要な情報と状態を適切に提示することができます。

管理者が得られるもの

自動化によって、

• 申請数、
• 現在の処理工程、
• 承認待ち、
• 期限超過、
• 新規サプライヤー登録状況、
• 請求書の差異、
• 繰り返し発生する例外、
• 工程ごとの処理時間

などを可視化できます。

Fluyentaの調達・企業業務向け機能でも、ボトルネック、SLA、タスク責任者、監査履歴などをモニタリングできる方向性を示しています。

目的は社員監視ではなく、業務改善です。

最初にどこから自動化するか

いきなり、「調達全体を自動化する」必要はありません。

例えば、

• 一つの事業部の購買申請・承認。
• 新規サプライヤー登録。
• PO承認。
• 請求書例外処理。

などから始められます。

成功した後で範囲を広げます。

実務的な進め方

1. 現在の業務を理解する
2. 人・システムを整理する
3. 手作業を見つける
4. 不要な工程を削る
5. 業務ルールを定義する
6. 最初の範囲を選ぶ
7. 必要システムと連携する
8. 例外ルートを作る
9. 実際に使う
10. 測定する
11. 拡張する

週単位で価値を届けるDXのガイドの「最初の価値を早く出す」という考え方ともつながります。

何を測るべきか

「システムが稼働したか」だけではありません。

元の課題に合わせて、

• 処理時間。
• 承認待ち。
• 二重入力。
• 進捗確認メール。
• 取引先登録の遅延。
• 請求書例外。
• 未処理案件。
• 状況確認に使う時間。

などを確認します。

調達自動化でよくある失敗

問題のある承認をそのまま自動化する

承認が7段階あるなら、本当に7段階必要かを先に考えます。

ポータルだけ作って業務とつなげない

それでは新しい受信箱になります。

ERP入力だけ自動化する

それ以前のメール・Excel作業が残ります。

明確なルールをAIに任せる

固定条件は通常ルールで十分です。

例外を設計しない

実務では例外が必ず発生します。

データの正本を決めないまま連携する

矛盾したデータがより速く広がる可能性があります。

必要のないERP刷新から始める

問題はERPの外側かもしれません。

経営側にとって「エンドツーエンド」とは

一つのシステムですべてを処理する必要はありません。

例えば、ポータルサプライヤーとの外部接点。

ワークフロー業務状態・承認。

ERPPO・財務記録。

文書管理契約・関連資料。

デジタルインボイス構造化された請求書。

AI一部の情報処理支援。

それぞれが役割を持ちます。

「エンドツーエンド」とは、その間の引き継ぎが意図的につながっていることです。

Axton Group × Fluyentaで考える調達自動化

Axton Group LTD Japanは、Fluyentaとの提携を通じて、日本企業の調達業務を「個別システム」ではなく「業務全体」として考えます。

Axtonは、日本側での業務理解、関係者とのコミュニケーション、業務整理、顧客との調整を担います。

Fluyentaは、20年以上のエンタープライズ業務自動化の経験を背景に、ワークフロー、システム連携、外部ポータル、モニタリングなどの技術を提供します。

Fluyentaの現在の製品情報でも、

• Vendor Onboarding、
• PO Approvals、
• Contract Management、
• Procurement Monitoring、
• Procurement-to-Delivery

などが調達向けの主要な業務として明記されています。

最初の問いは、「どの調達システムを入れ替えるべきか？」ではありません。

「現在の調達業務で、人が情報を移し、承認を追いかけ、システム間を手作業でつないでいる場所はどこか？」です。

そこから改善を始めます。

「デジタル購買」から「つながった調達」へ

調達DXは、紙を画面に変えることだけではありません。

Excel → Web版Excelでもありません。

本当の価値は、

• 上流で承認された情報を下流で再入力しない。
• 一度収集した取引先情報を別部門でもう一度集めない。
• 納品情報を請求書処理で利用できる。
• 例外には担当者が付く。
• 管理者は現在地を見られる。

という状態です。

そうすれば調達担当者は、

• データ転記、
• 確認メール、
• 状況追跡

ではなく、

• 取引先関係、
• 交渉、
• 条件、
• リスク、
• 商務判断

により多くの時間を使えるようになります。

それが、エンドツーエンドの調達業務自動化が目指すべき状態です。