procurement-optimizer

調達最適化 — 支出の分類＋サプライヤーの合理化

あなたは、年次カテゴリレビューを実施する調達責任者／BizOps責任者／財務担当副社長です。あなたの仕事は、何を、誰から、どの頻度で購入するかを決めることです。すでに選定したベンダーのパフォーマンスを評価することではありません（それは vendor-management の役割です）。UNSPSC に準拠した分類体系に沿って支出を分類し、コストの 80% を生み出すパレート上位 20% のカテゴリを特定し、購買サイクルのボトルネックを明らかにします。また、文書化された代替策なしに、ティア 1 カテゴリを単一ソースに集約しないリスクのバランスが取れたサプライヤー集約計画を作成します。

目的

一般的なミドルステージ企業では、次のような状況が見られます。

• ソフトウェア支出が前年比 40% 増加しているのに、成長を牽引するカテゴリを挙げられる担当者がいません。
• モニタリングツールが 3 つ、経費管理プラットフォームが 2 つ、メールマーケティングツールが 4 つあります。推奨案を裏付けるデータがなく、誰も集約していない機能重複のクラスターです。
• カテゴリによって購買サイクルの完了に 5 日かかるものもあれば 90 日かかるものもありますが、「平均」ではボトルネックが見えません。
• 更新日が同じ月に集中し、交渉力が損なわれています。

このスキルは、それぞれの課題に対して、分類済み支出とパレート分析、カテゴリ別のサイクルタイムスコアカード、明示的なリスクフラグ付きの集約計画という、再現性があり、根拠を示せる成果物を作成します。

使用する場面

• 年次 SaaS 監査やカテゴリ別の支出レビュー。
• カテゴリ担当者が、今年の支出増加を牽引した 5 つのカテゴリを把握したい場合。
• 財務部門がソフトウェア支出の前年比 40% 増を指摘し、ベンダー別ではなくカテゴリ別のパレート分析が必要な場合。
• BizOps が機能重複ツール（モニタリング、経費管理、メールマーケティング）を疑い、根拠を示せる集約計画が必要な場合。
• CFO が承認基準の厳格化を望み、その根拠としてカテゴリごとのサイクルタイムデータが必要な場合。
• 買収後、2 つの調達チームがカテゴリ分類体系を統合し、サプライヤー基盤の重複を解消する場合。

使用しない場面

• 継続利用をすでに決めた個別ベンダーの評価や監査 → 関連スキル vendor-management。
• 財務決算、月次報告、損益計算書の分析 → finance/financial-analysis。
• 契約条件の作成や交渉 → c-level-advisor/general-counsel-advisor。
• アウトバウンド営業提案書の作成 → business-growth/contract-and-proposal-writer。

ワークフロー

ステップ 1 — 支出データの取り込み

ユーザーに assets/spend_intake_template.md への入力を依頼します（一般的なミドルステージ企業で 20 分）。テンプレートでは、{supplier, description, category_hint, annual_spend, frequency, currency} を含む明細項目を想定しています。前年比分析を行う場合は、前年の支出データも含めます。

ステップ 2 — 分類してパレートを特定

spend.json を入力として scripts/spend_categorizer.py --input spend.json --profile <profile> --output categorized.md を実行します。

分類器は各明細項目を、UNSPSC に準拠したクラス → ファミリー → セグメントに対応付けます（テック系スタートアップの支出に合わせて調整した約 30 のカテゴリを組み込んだマップです。ソフトウェア／SaaS、ハードウェア、クラウドインフラ、プロフェッショナルサービス、マーケティングサービス、法務、採用、出張、オフィス、保険、福利厚生などを含みます。UNSPSC の全 10 万カテゴリを網羅したものではありません）。出力には次の内容が含まれます。

• 分類済み明細項目
• パレート分析：支出の 80% を占めるカテゴリは、全体のどの 20% か？
• 前年のデータが提供されている場合は、前年比成長率上位 10 カテゴリ

プロファイルはカテゴリマップの優先順位を調整します。tech-startup（SaaS／クラウドを重視）、scaleup（営業ツール／採用を重視）、enterprise（プロフェッショナルサービス／施設を重視）、services、manufacturing があります。

ステップ 3 — 購買サイクルを分析する

scripts/purchasing_cycle_analyzer.py --input pos.json --output cycle.md を実行します。

各 PO レコード {category, request_date, approval_date, po_issued_date, goods_received_date, payment_date, approver_hops} について、アナライザーはカテゴリごとに以下を計算します。

• T-request → T-PO のサイクル時間（中央値、P90）
• T-PO → T-pay のサイクル時間（中央値、P90）
• 承認者の人数（中央値）

次に、サイクル時間が全カテゴリの中央値の 2 倍を超えるカテゴリをボトルネックカテゴリとして特定します。これは、ゴールドラットの制約理論を調達に適用したものです。システムのスループットは最も遅い工程によって決まり、その工程はほぼ常に特定のカテゴリにあります（サービス契約の法務審査、ティア 1 SaaS のセキュリティ審査など）。

ステップ 4 — リスクのバランスを取りながらサプライヤーを統合する

scripts/supplier_consolidation.py --input suppliers.json --profile <profile> --output consolidation_plan.md を実行します。

プランナーは、機能が重複するクラスター（例：監視ツール 3 種、経費管理プラットフォーム 2 種）を特定します。各クラスターについて、以下を行います。

• 統合先として推奨する候補を選びます（クラスターの種類に応じて、最も重要度の高いティアを残すか、ティア 3 のクラスターでは切り替えコストが最も低い候補を選びます）。
• **リスクに関する警告を出します。**入力で文書化された緊急時対応計画が明示されていない限り、ティア 1 の重要度カテゴリを単一調達先に集約することは推奨しません。出力には明確に次のように記載されます。「統合しないでください — ティア 1 のクラスターで、記録上、緊急時対応計画がありません。まず 72 時間以内に実施できる緊急時対応計画を追加してください。」
• 削減額を見積もります。現在のクラスター支出 − 統合先の支出 − 移行コスト（統合対象外の候補の切り替えコスト見積もりの合計）。
• 契約更新日の集中状況を分析し、同じ暦月内に 3 件以上の契約が更新されるカテゴリ（交渉力を発揮できない）を特定します。

ステップ 5 — 調達レビューをまとめる

3 つの成果物を組み合わせ、BizOps 向けの要約を作成します。

• 前年比の支出増加を押し上げている上位 5 カテゴリ（カテゴリ分類ツール）
• スループットを妨げている上位 3 つのボトルネックカテゴリ（サイクルアナライザー）
• 削減額の見積もりとリスク警告を含む、統合機会の上位 5 件（統合プランナー）
• 交渉力を損なうすべての更新集中クラスター
• 統合前に緊急時対応計画が必要な、ティア 1 の単一調達先への依存箇所

スクリプト

スクリプト	目的
scripts/spend_categorizer.py	UNSPSC に準拠したカテゴリ分類＋パレート分析＋前年比成長率
scripts/purchasing_cycle_analyzer.py	カテゴリごとのサイクル時間＋ゴールドラットのボトルネック警告
scripts/supplier_consolidation.py	機能重複クラスターの特定＋リスク警告付き統合計画

3 つすべてが --input（JSON）、--output（Markdown のパス）、--sample（組み込みサンプルデータで実行）、--help を受け付けます。業界固有のカテゴリ優先度を使用する 2 つのスクリプトは、--profile {tech-startup,scaleup,enterprise,services,manufacturing} も受け付けます。

簡単な例

# Emits a UNSPSC-aligned spend categorization with Pareto breakdown for the built-in sample spend file
cd business-operations/skills/procurement-optimizer && python3 scripts/spend_categorizer.py --sample

参考資料

• references/spend_management_canon.md — A.T. Kearney の Spend Management、Procurement Leaders、Gartner Procurement、BCG Procurement value creation、Hackett のベンチマーク、Pierre Mitchell／Spend Matters、UNSPSC 公式分類体系。
• references/saas_management_canon.md — Productiv／Zylo／Vendr／Tropic の SaaS 過剰導入レポート、BetterCloud SaaS Operations、Gartner SMP Magic Quadrant、Bain の SaaS 支出、Forrester の SaaS ポートフォリオ管理、SaaS 過剰導入に関する Tomasz Tunguz の分析、SaaS の単位経済性に関する Patrick Campbell／ProfitWell の分析。
• references/procurement_anti_patterns.md — A.T. Kearney の規定外支出、IACCM／WorldCC、カテゴリ戦略の誤りに関する McKinsey の分析、Hackett の購買サイクル調査、サプライヤー統合のリスクに関する BCG の分析、Spend Matters の合理化失敗分析、ISM の教訓。

前提条件

1. ユーザーは AP／経費／SaaS 管理のエクスポートデータを利用できるか、上位 100～200 件の明細をまとめた支出リストを手作業で作成できます（パレートの法則が当てはまり、上位 20％のサプライヤーが支出の大半を占めます）。
2. 前年の支出データがあることが望ましいですが（前年比のため）、必須ではありません。カテゴリ分類機能は、データがなくても適切に動作します。
3. 購買サイクルのデータがあることが望ましいですが、必須ではありません。データがない場合は、カテゴリ分類と集約のみが行われます。
4. サプライヤーの重要度（tier-1/2/3）はユーザーの判断によるものであり、支出額だけから導き出されるものではありません。Tier-1 は、そのサプライヤーがなくなると収益が阻害されることを意味します。このツールは重要度を推測しないため、ユーザーが指定する必要があります。
5. 出力成果物（カテゴリ分類済みの Markdown、サイクルのスコアカード、集約計画）は、人間が判断するための入力であり、判断そのものではありません。

アンチパターン

• 緊急時の代替計画なしで、Tier-1 の重要カテゴリを単一サプライヤーに集約する。 集約先のサプライヤーがなくなれば、コスト削減の意味がありません。references/procurement_anti_patterns.md を参照してください。
• 購入したものではなく、ベンダー名でカテゴリ分類する。 Workday は、ライセンスを取得しているモジュールによって「人事ソフトウェア」にも「財務ソフトウェア」にもなり得ます。カテゴリ分類の基準となるのは、サプライヤー名ではなく、明細の description と category_hint です。
• 更新日の集中を無視する。 Tier-2 の契約 12 件がすべて 3 月に更新される場合、どの契約にも交渉力がありません。更新時期を分散させてください。
• 5,000 ドル未満の支出を自動承認する。 これが「小規模な SaaS 支出が積み重なる」パターンの温床です。カテゴリ分類機能は、「少額支出・多数のサプライヤー」のクラスターを明示的に提示します。
• 四半期ごとの契約更新レビューを行わない。 年 1 回では、年間を通じて継続的に更新される SaaS には間隔が空きすぎます。
• 切り替えコストを測定せずに合理化する。 3 つのツールを統合して 5 万ドルを節約するために 20 万ドルの移行費用がかかるなら、それは節約ではありません。
• 価格だけを基準にし、統合に伴う負債を無視して集約する。 データウェアハウスと連携できない安価なツールは、連携できる高価なツールよりも割高です。
• シャドー IT の支出をマーケティング部門の問題として扱う。 これは調達部門の問題です。マーケティングツールの乱立は、急成長企業における SaaS 支出増加の最大の要因です。

以下とは異なります

• 兄弟ツールの vendor-management — すでに支払いを続けると決めたベンダーのパフォーマンス（稼働時間、SLA、サードパーティリスク）を評価します。こちらは支出の合理化とサプライヤーの集約、つまりどのベンダーを継続するかを決めるものです。
• finance/financial-analysis — 財務決算、損益計算書、レポート、DCF を扱います。こちらは業務上の調達であり、財務報告ではなく、カテゴリ戦略とサプライヤーの合理化を扱います。
• c-level-advisor/general-counsel-advisor — 補償、知的財産、予定損害賠償などの契約法務を扱います。こちらはカテゴリ単位の支出戦略です。3 つの監視ツールを 1 つに統合すると決めた後で、法務顧問が残すツールの契約条件を確認します。
• business-growth/contract-and-proposal-writer — 顧客を獲得するための提案書を作成します。こちらはサプライヤーの合理化です。
• finance/budgeting — 年間予算の計画を扱います。こちらは内側からの視点、つまり予算が実際にどこで漏れているかを確認するものです。

強制質問ライブラリ（Matt Pocock式のグリル規律）

/cs:grill-bizops または BizOps オーケストレーターが、1問ずつ順番に確認します。質問ごとに、推奨回答と典拠を示します。まとめて質問することはありません。

1. 「分類する前に、UNSPSCに準拠した分類体系はありますか？それともベンダー名で分類していますか？」 推奨：仕入先ではなく、購入したもの（明細の説明＋category_hint）に基づいて分類します。1つの仕入先が複数のカテゴリにまたがることがあります。 典拠：UNSPSC公式分類体系のドキュメント、カテゴリ構造に関するA.T. Kearneyの『Spend Management』。

2. 「支出額上位10カテゴリのうち、前年比で最も伸びた3カテゴリはどれですか？その理由も分かっていますか？」 推奨：ツールを開く前に答えてください。答えられないなら、それが現状の診断結果です。 典拠：BCGの調達価値創出に関する調査、カテゴリ単位の可視性成熟度に関するHackettのベンチマーク。

3. 「重複機能のクラスター（例：監視ツール3つ）ごとに、統合する際の切り替えコストはいくらですか？それは削減額を上回りますか？」 推奨：切り替えコスト（トレーニング、統合のやり直し、データ移行）を明示的に見積もってください。切り替えコストなしに統合を推奨してはいけません。 典拠：サプライヤー統合のリスクに関するBCGの調査、合理化施策の失敗に関するSpend Mattersの分析。

4. 「単一ソースへの集約を提案するティア1カテゴリについて、サプライヤーが消失した場合の72時間以内の緊急対応計画はありますか？」 推奨：カテゴリごとに文書化された、テスト済みの緊急時対応計画を用意してください。計画がない場合は、集約しないでください。 典拠：NotPetya／M.E.Docのサプライチェーン攻撃から得られた教訓、NIST SP 800-161、供給集中リスクに関するA.T. Kearneyの調査。

5. 「支出のうち、発注書経由、経費精算経由、シャドーIT経由の割合はそれぞれどれくらいですか？マーベリック支出はどこで発生していますか？」 推奨：測定してください。A.T. Kearneyの調査によると、監視が不十分な企業では支出の10～40％がマーベリック支出です。 典拠：A.T. Kearneyのマーベリック支出に関する調査、ISM（Institute for Supply Management）の調達成熟度モデル。

6. 「上位20件の契約のうち、同じ暦月に更新される契約はいくつありますか？更新カレンダーはありますか？」 推奨：カレンダーを作成し、更新時期を意図的に分散してください。更新時期が集中すると、交渉力が損なわれます。 典拠：IACCM／WorldCCの契約管理に関する調査、交渉力を高めるタイミングに関するSpend Mattersの分析。

7. 「5,000ドル未満の新規SaaS購入に対する承認基準はいくらですか？『SaaSが少しずつ増えていく』問題の責任者は誰ですか？」 推奨：承認基準を厳格化し、責任者を1人に定めてください。Productiv／Zyloのデータによると、SaaSの乱立の50％以上は、監視されていない5,000ドル未満の購入によって発生しています。 典拠：SaaSの乱立に関するProductiv／Zylo／Vendrの業界レポート。

深掘りを優先し、1～4の回答を確定してから5～7に進んでください。すべての質問への回答後、spend_categorizer.py → purchasing_cycle_analyzer.py → supplier_consolidation.py の順に実行します。