ERPの「外側」にある競争優位を、誰が実装するのか

Formulaがなぜ存在するのか。ERPでもSaaSでもなく、なぜFormulaなのか。

自分の中でようやく言語化するに至ったので、それを一枚の図で説明する。業務プロセスを「レイヤー」で分解する考え方だ。今日はその話をする。

業務には「層」がある

ある業務プロセスを横に分解してみる。たとえば「購買見積」なら、作成 → 送信 → 比較 → 合意という業務プロセスの流れがある。見積書を作り、サプライヤーに送り、回答を比較し、条件を合意する。

次に、そのプロセスを縦に分解する。同じ「作成」でも、中身の複雑さ・独自性は企業によって全然違う。

• レイヤー1 ― 見積書のフォーマットを埋めるだけ。どの会社でもやる標準作業。
• レイヤー2 ― 作成前に、過去の取引実績を調査し、社内でブリーフィングをかけている。
• レイヤー3 ― 見積を比較するとき、価格だけでなく、自社独自の評価軸で多面的に比較している。
• レイヤー4 ― 合意に至るまでに、自社固有の承認フロー、例外判断、部門横断の調整が走っている。

この「縦の層」が、すべてを決める。

レイヤー1はERPの仕事

レイヤー1は、どの企業でもやる標準業務だ。見積書を出す。請求書を受ける。在庫を記録する。これは「法規制対応のために生まれた」領域であり、正確に記録することが目的だ。

ERPは、まさにこのために存在する。System of Record。記録の正本を持つシステムだ。SAPが世界中の企業に導入されてきた理由は、この標準業務を正確に、確実に、安定して回せるからだ。

レイヤー1をERPがやること自体は、何も間違っていない。

問題は「レイヤー2〜4をERPでやろうとする」こと

自社独自の比較ロジック、調査プロセス、承認フローを、ERPのモジュール拡張でやるべきではない。

なぜか。ERPは低位標準化のソフトウェアだ。標準プロセスに業務を合わせる思想で設計されている。「誰がやっても同じ結果になるべき業務」に最適化されている。

しかし、レイヤー2〜4は違う。ここは「企業が独自のやり方をしているからこそ、それが競争優位を生んでいる」領域だ。独自プロセスであることそのものが、価値の源泉なのだ。

これをERPの標準モジュールに押し込めると、二つの問題が起きる。一つは、カスタマイズの保守コストが膨れ上がり、アップグレードのたびに地獄を見ること。もう一つは、もっと本質的な問題だ。自社の強みの領域まで低位標準化に合わせてしまうことで、競争優位性そのものを失う。標準化すべきでないものを標準化してしまうのだ。

SaaSでも解けない理由

ではSaaSはどうか。「レイヤー1がERPなら、レイヤー2〜4をSaaSでやればいいのでは？」と思うかもしれない。

しかし、この領域がSaaSで埋まるほど、エンタープライズの業務はシンプルじゃない。SaaSで埋まるほどだったら、もう取られている。取られているか、市場として小さいかのどちらかだ。

エンタープライズの独自業務領域は、企業ごとに違いすぎて、汎用的なSaaSでは吸収しきれない。これはA00が見ている世界と同じだ。

Formulaは「オーバーレイ」である

ここまでの話を踏まえると、Formulaのポジショニングが一つの図で説明できる。

Formulaは、ERPを置き換えるのではない。ERPの上にオーバーレイとして乗る。

ERPからは元データをもらう。独自業務のオペレーション（調査、比較、判断、調整）はFormulaで行う。完了したデータだけをERPに戻す。途中経過の「遷移」はERPに渡す必要がない。

これが、PortXが「競争優位そのものを実装する」と言っている意味だ。レイヤー1（標準業務・記録）はERPに任せ、レイヤー2〜4（独自業務・競争優位の源泉）をFormulaで実装する。

なぜ今なのか

「そんなの昔から分かってたことじゃないか。なぜ今までやらなかったのか」

答えはシンプルだ。今まではコストが高すぎた。

レイヤー2〜4は企業ごとに違う。個別に設計し、個別にコードを書き、個別にテストし、個別に運用保守する必要がある。従来のSIではそのための知的作業コスト（要求整理、設計書作成、仕様の構造化、変更影響の追跡...）が膨大だった。だから結局、ERPのモジュール拡張という「無理な選択肢」を取るか、独自開発に何年もかけるしかなかった。

LLMがこの知的作業コストを大幅に下げた。そして、Formulaがそれを「実務として成立させる基盤」に変えた。

要するに、今まで「高すぎてERPに押し込めるしかなかった独自業務」を、現実的なコストでシステム化できるようになった。それがFormulaのWhy Nowだ。

独自プロセスは「バグ」じゃない。「強さ」だ

ERPベンダーやコンサルは、よく「業務を標準化しましょう」と言う。それ自体は、レイヤー1の話としては正しい。標準化できる部分は標準化すべきだ。

しかし、レイヤー2〜4に残っている独自プロセスを見て「これは非効率だから標準化しましょう」というのは、的外れなことがある。その独自プロセスこそが、その企業の強さの源泉だからだ。

大手製造業が長年かけて磨き上げてきた、自社独自の調達評価、生産調整、在庫判断、配車ロジック。それは「ERPに合わせるべき非効率」ではなく、「コード化して磨き上げるべき競争優位」だ。

Formulaは、その競争優位をコード化するために存在している。

ERPを本当に理解している人は、ERPの「外側」があることを知っている。全部を自分たちでやろうとするのは、低位標準化のソフトウェアを理解していない証拠だ。

その外側にこそ、顧客の競争優位がある。PortXは、その外側を実装する会社だ。

ERPがない領域でも「層」を分けて考える

ここまでERPとFormulaの棲み分けを話してきたが、もう一つ重要なことがある。

実際には、ERPが入っていない業務領域もたくさんある。全部がSAPで管理されている企業の方がむしろ少ない。

その場合でも、この「レイヤーで分けて考える」思想は同じだ。Formulaで業務をシステム化するとき、L1（標準的な記録・処理）とL2〜L4（独自の判断・ロジック）を分けて設計することが重要になる。

なぜか。L1は将来ERPやSaaSが入る可能性がある。あるいは他システムとのデータ連携が必要になる。そのとき、L1とL2〜L4が混在した設計だと、切り分けられなくなる。最初から層を分けて設計しておけば、L1の部分をERPに委譲することも、L2〜L4だけを磨き続けることも、柔軟にできる。

つまりFormulaでシステムを作るときも、「ここは標準的な記録処理」「ここは独自の競争優位ロジック」と意識的に分けて設計していく。この考え方こそが、Formulaで正しく業務をシステム化するための設計原則だ。