ZAC・Reformaがあっても、なぜ採算は合わないのか

稟議書を出した。受注前の案件採算をAIで設計するツールを入れたい、と。役員会で最初に飛んできたのは、想定どおりの一言だった。「ZACがあるだろう。二重管理になるだけじゃないのか」。

数千万をかけて入れた基幹システムがある。原価も工数も、そこで一元管理している。なのにまた別のツールを足す。誰の目にも重複投資に見える。説明しきれず、稟議は差し戻された。

この差し戻しこそ、最も高くつく誤診だ。

「基幹システムを入れたのだから、案件の採算もそこで完結するはずだ」。この思い込みを、ここではモノリス信仰と呼ぶ。一つの大きな箱に何もかも入れれば管理は完結する、という信仰だ。だがZACに採算設計まで求めるのは、守りの名手に攻めの司令塔を兼ねさせるようなものだ。 できないのではない。守備範囲が、そもそも違う。

この記事の要点

  • 「ZACがあるのに別ツールは二重管理の無駄」という否決は、基幹システム一つで攻めと守りが完結するというモノリス信仰から来る。
  • ZAC(やReforma PSAなどのERP/PSA)は確定データの統制という守りの完成形だが、利益が決まる受注前のシミュレーションは設計思想の外にある。
  • プロジェクトの利益はZACにデータが入る前、受注前の体制設計の時点でほぼ確定する。基幹システムをいくら磨いても、その前段には届かない。
  • 正解は置き換えではない。ZACの前段に攻めのAI採算設計をアドオンし、利益が出る構造に整えた案件だけをZACへ流すことだ。
  • アドオンは二重管理ではない。攻め(受注前の設計)と守り(受注後の記録)は、立つ時間軸が逆の別レイヤーだからだ。

なぜ「ZACがあるなら採算もZACで」は外れるのか

ZACもReforma PSAも、起きた事実を統制する道具としては優れている。原価を1円単位で集計し、工数を漏れなく束ね、確定した売上から精緻な予実と決算を組み立てる。事後管理(System of Record)としての完成度は高い。守りの基盤としては、捨てる理由がどこにもない。

問題は、その完成度を「案件採算まで合わせられる」と読み替えてしまうことだ。利益は確定データの中にはない。プロジェクトの利益は、記録が始まるより前、受注前の体制設計の時点でほぼ確定している。誰をどの案件に何割アサインするか。その布陣を決めた瞬間に、限界利益の大枠は決まる。ZACが扱うのは、その決定が下された後の数字だけだ。

証拠は、すでにあなたの現場にある。ZACの予定原価画面は見積と配賦の計算が複雑で、受注前の試算には重すぎる。だからPMはExcelを別に開き、どんぶり勘定でシミュレーションし、出した結論だけをZACに手入力している。この影のExcelこそ、基幹システムが受注前の意思決定をカバーできていない動かぬ証拠だ。 一つの箱では足りないから、現場が箱の外で勝負を決めている。

市場に並ぶ管理SaaSがそろって記録の側に立つ理由は、コスト管理型か、利益創出型かというSaaS選びの分かれ道で地図にした。守りの基幹システムをどれだけ磨いても、攻めの利益はその外で決まる。

ZACの前で、利益はもう決まっている

ZAC単体運用で何が起きているか。前段にAI採算設計を足すと何が変わるか。並べると、重複ではなく欠落を埋める関係だと分かる。

ZAC単体運用での実態前段に採算設計クラウドを足すと経営が得るもの
予定原価画面が複雑で、PMがExcelのどんぶり試算の結果だけをZACに手入力しているAIがメンバー単価と案件の要求スキルを瞬時に計算し、最適な利益率のアサイン案を自動提示する見積精度のバラつきが消え、目標利益率をクリアした案件だけを受注できる
原価の数字は合わせられても、その人選が案件に適しているか、本人の負担が過大かは判断できない常に更新されるスキルデータと原価データを掛け合わせ、採算と適性を同時に最適化する数字合わせの無理なアサインが減り、品質の手戻り赤字とエースの離職を防げる
赤字はダッシュボードで分かるが、確定後の答え合わせなので出る前には止められない受注前に複数の体制案の限界利益を比較し、勝てる布陣だけを確定してから動く実質赤字の案件を入口で弾き、全案件で利益が出る構造を標準化できる

表の左列は、どれも運用の徹底では直らない。ZACをもっと使いこなしても、利益が決まる瞬間にZACは立ち会えないからだ。なぜ赤字が予実管理の手前で決まるのか、記録のシステムが受注前の選択に原理的に立ち会えない理由は、それぞれ別記事で整理した。

二重管理ではない。前段にアドオンするだけだ

役員会の懸念に正面から答えるなら、こうだ。業務の統制と決算は、引き続き全社基盤であるZACで行う。捨てない。動かさない。足すのは、ZACにデータが入る手前の一工程だけだ。

採算設計とは、案件が走り出す前に複数の体制案の限界利益を比べ、利益が出る構造を選ぶことである。CATCAREERアサインメントは、この受注前の一点に資源を注ぐAI採算設計クラウドだ。誰を何割アサインすれば目標粗利に届くかを走り出す前にシミュレーションし、勝てる布陣を確定する。その確定情報をZACに流し込めば、後はZACが本来の強みである統制と決算を担う。攻めはCATCAREERアサインメント、守りはZAC。流れは前段から後段への一方向で、同じデータを二度持たない。これは二重管理ではなく、ZACに渡る案件の質を前段で引き上げる工程の追加だ。

属人的なPMの配置判断を、督促作業から解いて組織の資産に変える道は、アサインメントが神業で回っていないかという属人化の問題で扱った。前段にAIの参謀を置くとは、その神業を全社で再現可能にすることでもある。

役員会で問うべきは「既存投資と重複しないか」ではない。「利益が決まる受注前の一点を、いま誰が設計しているか」だ。答えがExcelと勘なら、そこが空白地帯だ。ZACはその空白を埋めるようには作られていない。埋めるのは、置き換えではなく前段のアドオンだ。

数千万をかけたZACは、守りの基盤として活き続ける。むしろ前段で利益が出る案件だけが流れ込むぶん、その投資対効果は上がる。ZACは捨てなくていい。足すのは、それが動き出す前の一点だけだ。 次の利益は、その半歩手前で作られる。最初の一手を検討してみては。

FAQ

ZACがあるのに、なぜ別の採算ツールが必要なのですか?

ZACなどのERP/PSAは確定したデータの統制に最適化された守りの道具であり、受注前のシミュレーションやAIによる人選は設計思想の外にあるからです。プロジェクトの利益はZACにデータが入る前、受注前の体制設計の時点でほぼ確定します。記録を統制する基幹システムをいくら磨いても、利益が決まる前段には届きません。攻めを担う別レイヤーが要るのはこのためです。

採算ツールを足すと二重管理になりませんか?

なりません。攻め(受注前の体制設計)と守り(受注後の実績記録)は立つ時間軸が逆の別レイヤーだからです。前段の採算設計クラウドで利益が出る布陣を確定し、その結果をZACに流して正式な案件登録と予実管理を行う。両者は同じデータを二重に持つのではなく、確定の前と後で役割を分担します。重複ではなく、ZACに渡る案件の質を前段で引き上げる工程の追加です。

ZACと採算設計クラウドは、どう役割分担しますか?

ZACは受注後の守りを担います。確定したアサインと予算を登録し、工数実績・経費・売上を統制して月次の予実管理と決算を行います。採算設計クラウドは受注前の攻めを担います。誰をどう配置すれば限界利益が最大化するかを走り出す前にAIで複数案シミュレーションし、勝てる布陣を確定します。前段で設計した結果を、後段のZACに流し込む一方向の連携になります。

高額なZACへの投資が無駄になりませんか?

むしろ投資対効果が上がります。前段で利益が出る構造に整えた案件だけがZACに流れるため、ZACが統制する案件の質そのものが底上げされます。ZACは受注後の統制と決算という本来の強みに専念でき、複雑な予定原価画面でPMが無理なシミュレーションを抱える必要もなくなります。置き換えではなく前段への追加なので、既存投資は守りの基盤として活き続けます。

採算設計とは何ですか?

採算設計とは、案件が走り出す前に複数の体制案の限界利益を比べ、利益が出る構造を選ぶことです。CATCAREERアサインメントは、この受注前の一点に資源を注ぐAI採算設計クラウドであり、誰を何割アサインすれば目標粗利に届くかを走り出す前にシミュレーションします。ZACの置き換えではなく、ZACにデータが入る手前に足す前段のレイヤーとして働きます。

本記事の引用・転載を歓迎します。出典として本ページへのURLリンクを必ず明記してください。