「運転資本を圧縮しよう」と経営会議で決まり、財務が毎月CCC（キャッシュ・コンバージョン・サイクル）を報告するようになった。半年後、数字はほとんど動いていない――この光景を、SAPを入れている会社でも繰り返し見てきた。原因ははっきりしている。CCCは結果指標であって、行動指標ではないからだ。回収条件を決めるのは営業、在庫を積むのは生産と購買、支払条件は調達が握る。財務が全社平均の日数を配るだけでは、誰の明日の行動も変わらない。本稿は、SAPに溜まっている伝票とマスタを使って、CCCを「名指しできる例外」まで分解し、現金に変える手順を書く。

POINT
CCC改善が止まるのは努力不足ではなく設計ミス。全社平均の「日数」を配るのをやめ、SAPの伝票粒度で「どの顧客・どの品目・どの仕入先が現金を寝かせているか」を名指しし、各部門の例外キューに落とす。運転資本は精神論ではなく、マスタ設定の結果である。

CCCを3つの日数に割り、責任者を付ける

CCCの定義は単純だ。売上債権回転日数（DSO）と棚卸資産回転日数（DIO）を足し、仕入債務回転日数（DPO）を引く。現金が仕入で出ていってから、販売代金で戻ってくるまでの日数である。

CCC＝現金を立て替えている正味の日数（DPOはマイナス項）
DSO 売上債権回転日数（営業）
＋
DIO 棚卸資産回転日数（生産・購買）
＋
（−）DPO 仕入債務回転日数（調達）
=
CCC 現金を立て替える正味日数
式は単純。問題は、3つの日数の持ち主がすべて財務の外にいること。

単純な式なのに改善が進まないのは、3つの日数の持ち主がバラバラだからだ。DSOは営業の受注条件と回収実務、DIOは生産計画と購買のロット、DPOは調達の交渉条件で決まる。つまりCCC改善とは財務のプロジェクトではなく、営業・生産・購買それぞれの行動変容のプロジェクトであり、財務の仕事は「全社の日数を報告すること」ではなく「各部門が自分ごととして動ける粒度まで数字を割ること」にある。

ここで全社平均のまま議論すると、必ず「うちの業界は回収サイトが長いから仕方ない」という一般論に着地する。議論を前に進めるには、平均をやめて分布を見るしかない。そしてその分解は、SAPの中に材料が全部ある。

運転資本は「マスタ設定の結果」である

SAPを入れている会社の本当のアドバンテージは、集計が速いことではない。すべての債権・債務・在庫が伝票とマスタに紐づいていて、日数の「原因」まで遡れることだ。

見るべき場所は3つある。

SAP上でCCCを『名指しできる例外』に分解する
STEP 1
日数を分布に割る
顧客別・品目別・仕入先別に回転日数を並べ、平均を歪めている上位を特定する
→
STEP 2
原因マスタに遡る
支払条件・与信限度・安全在庫・ロットサイズなど、日数を生んでいる設定を突き止める
→
STEP 3
例外キューに落とす
「条件外の滞留」だけを担当者の作業リストにして週次で回す
土台債権・債務・在庫が伝票粒度でマスタに紐づいているというSAPの構造。集計ツールとしてでなく、原因追跡の台帳として使う
月次のCCC報告会ではなく、週次の例外処理で数字は動く。

第一に支払条件マスタ。DSOの多くは、回収が遅いのではなく「そもそも長い条件で売っている」ことが原因だ。顧客マスタの支払条件を棚卸しすると、標準条件から逸脱した個別条件が営業の現場判断で積み上がっているのが普通である。値引きは損益に出るから統制されるが、回収条件の譲歩は損益に出ないから野放しになる。ここに気づくと、DSO改善の主戦場は督促ではなく「受注時の条件統制」に移る。

第二にMRPパラメータ。在庫日数は、現場の「積みすぎ」の前に、品目マスタの安全在庫・発注点・ロットサイズが決めている。何年も見直されていない安全在庫設定は、その分だけ現金を倉庫に固定し続ける。DIOの議論を「在庫を減らせ」という号令でなく「この品目群の安全在庫パラメータを需要実績で再計算する」という作業に変換できるかが分かれ目だ。

第三に滞留の例外管理。期日超過債権を「合計いくら」で見ても動けない。SAPの債権明細を期日・顧客・担当で切り、「条件どおりに入っていない伝票」だけを回収担当の作業リストにする。入金消込の自動化では、過去の消込履歴を学習して銀行入金と債権を突き合わせるSAP Cash Applicationのような機械学習ベースの仕組みも提供されている（SAP Cash Application）。消込が自動で片づくほど、人は「消せない入金＝異常」の処理に集中でき、滞留の発見が早まる。

MEMO
正直に書くと、SAPを入れただけでCCCが自動で出てくるわけではない。DSO/DIO/DPOの定義（連結か単体か、月中平残か期末か）を財務が一度決めて固定する作業が先にある。また機械学習消込は過去の消込履歴という学習データが要るため、稼働直後から精度が出るものではない。ここを飛ばして「システムで見える化」と言うから、掛け声で終わる。

「集計で終わる会社」と「現金を生む会社」の違い

同じSAPを使っていても、運転資本が動く会社と動かない会社では、使い方がまるで違う。

同じSAPでも、運転資本への効かせ方は二極化する
動かない集計で終わる会社
見える化 ●●●
行動への接続 ●○○
継続性 ●○○
月次でCCCと日数推移をレポート。全社平均を役員会で眺め、「改善しよう」で散会。数字の持ち主が決まっておらず、翌月も同じグラフを見る。
動く現金を生む会社
見える化 ●●●
行動への接続 ●●●
継続性 ●●●
条件外の滞留債権・パラメータ未見直し品目・標準外の支払条件が、担当者別の例外キューで週次に回る。役員会が見るのは平均日数でなく「例外の消化率」。
違いはシステムの機能ではなく、数字を『誰の作業リスト』に落としているか。

要するに、経営会議で見るべきKPIは「CCC何日」ではない。**「標準条件から外れている債権・在庫・債務が、どれだけの現金を寝かせていて、今月いくら回収したか」**だ。日数は結果として縮む。

この構図は、ROIC経営が「ツリーを配っただけ」で形骸化するのと同型である（ROIC経営が3年で形骸化する理由）。全社指標を現場の言葉に翻訳しない限り、指標は壁に貼られたポスターで終わる。運転資本における「現場の言葉」が、支払条件マスタでありMRPパラメータであり、例外キューなのだ。

90日で回し始めるための着手順

大きな仕組みを作る前に、いま入っているSAPのデータで始められる。

最初の90日でやることは4つに絞る
  • DSO/DIO/DPOの計算定義を財務が決めて固定する（対象範囲・平残か期末か・連結か単体か）
  • 顧客マスタの支払条件を棚卸しし、標準条件からの逸脱リストを営業責任者と共有する
  • 在庫金額上位の品目群について、安全在庫・ロットサイズの設定日と根拠を確認する
  • 期日超過債権を担当者別の例外リストにし、週次のレビューを回収・営業・財務で始める

注意点をひとつ。DPO（支払を延ばす）は3つの中で一番手を付けやすく見えるが、一番慎重にやるべきレバーだ。自社の支払サイト延長は、そのまま仕入先の資金繰り悪化になる。取引先との力関係で押し込んだDPOは、価格や供給の安定性で返ってくることが多い。まず自社の中で完結するDSOの条件統制とDIOのパラメータ見直しから着手し、DPOは調達戦略として個別に交渉するのが実務的な順番である。

運転資本の圧縮は、利益を1円も増やさずに手元現金を増やせる、数少ない打ち手だ。そしてSAPを使っている会社なら、そのための台帳はすでに社内にある。足りないのは新しいシステムではなく、「平均を配る報告」から「例外を消す運用」への切り替えである。

まとめ
CCCは結果指標。動かすには原因の粒度まで割る。 ①DSO/DIO/DPOに分解し、営業・生産購買・調達へ責任を割り付ける。②運転資本はマスタ設定の結果――支払条件マスタ・MRPパラメータ・与信設定に遡る。③全社平均の月次報告をやめ、「条件外の例外」を担当者別キューで週次に回す。④着手はDSOの条件統制とDIOのパラメータ見直しから。DPOは仕入先の資金繰りに直結するため調達戦略として個別に扱う。SAPは集計ツールでなく、原因追跡の台帳として使ったときに現金を生む。

関連記事