「案件別の採算がSAPから出てこない」という相談は、たいてい同じ形をしている。SAPには原価が入っている。工数も入っている。それなのに、案件ごとの粗利は経理がExcelで組み直していて、出てくるのは決算が締まった後だ。ここで多くのプロジェクトが「PSモジュールを入れれば解決する」という方向に進む。だが器を足しても、たいてい状況は変わらない。案件採算の設計とは、原価を集める器を作る作業ではなく、見積の一行と実績の一行を同じキーで並べられるようにする作業である。 営業はフェーズ別・役割別に工数を積んで見積り、実績は月別・社員別に入ってくる。この二つは、どれだけ精緻に原価を集めても突き合わない。
内部指図とWBS、どちらを使うか
判断は好みではなく、必要な機能で決まる。内部指図（KO01で作成、KO22で予算、KO88で決済）は単一階層のコストコレクタだ。軽く、大量に作れて、運用の教育コストが低い。展示会一回、金型一型、小規模な改善案件のように、始まりと終わりがあって階層を持たない仕事に向く。
WBS要素（CJ20Nのプロジェクトビルダーで作成、CJ30で予算、CJ88で決済）は階層を持つ。上位に予算を置いて下位に配分でき、日程を持ち、上位で集計しながら下位で実績を受けられる。フェーズごとに検収する案件、部分請求のある案件、進行基準で収益を認識する案件はWBSでないと組めない。
ここで一つ、設計レビューで確かめておきたい点がある。統計指図（統計転記のみの内部指図）を実績の受け皿にしようとする設計だ。統計指図は、実原価を受けている原価センタの横で「もう一つの見方」を持つための仕組みで、それ自体は決済されない。案件の原価を集めてCO-PAや資産へ流したいなら、実オーダとして立てる必要がある。この取り違えは、稼働してから決済が通らないことで発覚する。
器は好みでなく、階層・日程・部分請求が要るかどうかで決まる
見積の分解と、実績の分解を一致させる
WBSの階層を、社内の組織や工程の呼び名で切っている案件は多い。だが比較したいのは組織ではなく、見積だ。受注時に「要件定義200時間、設計400時間、開発900時間」と積んだのなら、WBSもその三つで切る。逆に、見積が一式で出ているのに実績だけを細かく分解しても、突き合わせる相手がいないので誰も見ない。
粒度を上げすぎる失敗も同じ頻度で起きる。WBSを50も100も切ると、現場は工数入力のたびにどこに付けるか迷い、迷った結果は「とりあえず一番上」に集まる。実績の粒度は、見積の粒度を超えてはいけない。 超えた分は入力精度の劣化として返ってくる。
見積と同じ粒度でWBSを切ると、見積の一行と実績の一行が並ぶ
工数は、活動タイプ単価を通って原価になる
ここがプロジェクト採算の心臓部で、同時に最も設計が雑になる場所だ。
工数はCATS（CAT2、S/4HANAのFioriなら「マイタイムシート」系のアプリ）で入力され、CAT5でプロジェクトへ、CAT7でCO（原価センタ・内部指図）へ転送される。転送された時点で金額に化けるが、その単価は給与実績ではない。原価センタと活動タイプの組み合わせに対してKP26で計画した活動単価だ。つまり期中に見えている案件原価は、実際の人件費ではなく、計画単価で評価された金額である。
差額は原価センタに残る。実際の人件費と、案件へ払い出した金額の差は原価センタの差異として滞留し、KSIIで実際の活動価格を計算し、KON2（内部指図）やCON2（プロジェクト）で再評価を転記するまで案件には落ちない。前提として、活動タイプのマスタ側で実際価格による再評価を許可しておく必要がある。多くの会社はこれを期末にしか実行しない。だから「案件の実績原価は決算後にしか分からない」という状態が生まれる。裏を返せば、月次で実行する設計にすれば月次で見える。
期中の案件原価は計画単価の金額で、実際との差は再評価するまで原価センタに残る
もう一段、経営に効く論点がある。活動単価の分母だ。原価センタの計画原価を年間の所定労働時間で割れば単価は低くなり、稼働率が80%なら残り20%分は吸収されずに原価センタへ残る。請求可能時間の計画値で割れば単価は高くなり、案件が部門の全コストを負担する。
分母を所定労働時間に置けば、稼働率の悪化が案件の赤字に化けない
収益を同じ器に載せないと、案件の粗利は出ない
原価側だけを整えて、収益側を忘れている設計は少なくない。売上はSD（販売管理）から会社コード・利益センタへ流れるが、それだけではWBSに紐づかない。受注明細のアカウントアサインメントにWBS要素を指定して初めて、収益と原価が同じ器の上で並ぶ。ここを運用で徹底できないと、案件別P/Lは原価だけの表になる。
そのうえで、S/4HANAには収益認識のタイミングそのものを変える仕組みがある。従来のECCでは、月次の締め処理で結果分析（Results Analysis）を一括実行して仕掛品と収益を計算し、決済で財務へ落としていた。粒度は締めのバッチ単位で、転記の都度ではない。S/4HANAのイベントベース収益認識（Event-Based Revenue Recognition）は、工数の確定や仕入請求が転記されたその瞬間に、収益・売上原価・仕掛品を計算して仕訳を作る。ユニバーサルジャーナル（ACDOCA）に即座に載るため、締めを待たずに案件の粗利が見える。適用対象は顧客プロジェクトや受注明細に紐づくものが中心で、すべての案件に無条件で効くわけではないが、専門サービス型の事業ならまず射程に入る。
イベントベース収益認識なら、締めを待たずに案件の粗利が見える
つまり、「締めが終わらないと案件の粗利が分からない」はS/4HANAでは設計の選択の結果であって、システムの制約ではない。 選ばなかった理由が「移行スコープに入らなかった」なのか「収益認識の要件を詰め切れなかった」なのかは、稼働後に問われる。
案件の原価と収益を1本にするには、この順で決める。逆順にすると組み直しが生じやすい。
決済の設計が、案件の数字の行き先を決める
内部指図やWBSに集まった原価は、そこに置いたままでは会計の外にある。決済プロファイルと決済ルールで、どこへ落とすかを決める。費用で終わる案件ならCO-PAや原価センタへ、資産になる案件なら建設仮勘定（AuC）を経て本勘定へ。この設計を後回しにすると、稼働後に「指図に残高が残り続けている」という現象で表面化する。
決済先をCO-PAに置いておけば、案件の採算を顧客別・製品別の収益性分析と同じ土俵で見られる（CO-PA（収益性分析）で、どの製品・どの顧客が儲かっているかをどう出すか）。逆に、案件単位でしか見ない設計にすると、赤字案件が特定顧客に偏っているのか、特定の見積パターンに偏っているのかが分からないまま終わる。
あるシステム開発会社で、PSモジュールは稼働から3年動いていた。WBSは案件ごとに20〜30本切られ、工数はCATSから毎週入っていた。それでも案件別の粗利は経理が四半期に一度Excelで作っていた。分解して分かった原因は二つだ。一つは、受注明細にWBSを割り当てる運用が営業側で定着せず、収益がWBSに乗っていた案件が半分以下だったこと。もう一つは、実際活動価格計算を年一回しか実行しておらず、期中の原価が数年前に作った計画単価のままだったことだった。手を入れたのは設定ではなく運用で、受注登録の必須項目化と、実際活動価格計算の月次化の二つだけ。四半期に一度だった案件別P/Lは、翌四半期から月次の締めと同時に出るようになった。営業側の抵抗は、受注登録の入力項目が増えることへの反発として最初の1か月だけ出た。案件別P/Lが自分たちの見積精度を映す資料でもあると分かった時点で、それは消えた。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
「入れたのに出てこない」の答えは、たいてい入力の手前にある
案件採算がSAPから出ないとき、疑うべき順序は決まっている。収益が器に乗っているか。見積の軸と実績の軸が一致しているか。単価がいつの計画値か。決済が実行されているか。この四つを確かめる前にモジュールを追加しても、出てこないものは出てこない。SAPは、集めろと言われたものしか集めない。何を集めるかを決めているのは、受注登録の画面と、見積を作っている営業の頭の中である（プロジェクト型事業の採算管理、工数原価と稼働率で受注前に赤字案件を止める）。
