このオファをいつ・誰に当てるか
典型顧客像
- 化学・素材・製鉄・製紙メーカーの工場サイト
- 連続プロセスかつ 連産品（複数製品が固定比率で同時生産）
- 中間品の在庫バッファが極めて小さい（タンク1日分未満）
- パイプラインで顧客と直結している
- 本社DX組織と工場現場の橋渡し役（窓口）が存在
業務痛シグナル — このフレーズが出たら当てる
- 「連産品で生産比率が固定で、片方だけ調整できない」
- 「中間品のタンク在庫が1日分もない」
- 「上流と下流の調整で日々喧々諤々の会議をしている」
- 「電気的計測器はあるのに目視のほうが信頼されている」
- 「N時間後の予測はできるはずだが、できていない」
- 「ファクター多すぎて『そんなの無理』と言われる」
- 「ベテラン退職で属人化リスクが高い」
業務状態の変化（Before / After）
機能ではなく、意思決定と業務状態がどう変わるか で表現する。営業時はこの変化を主役に置く。
Before — 現状の業務状態
- 部門ごとに自部門を守る部分最適
- 現時点のスナップショットしか見えない
- ベテランの肌感に依存した判断
- 調整が日々の喧々諤々会議で行われる
- 需給逼迫が起きてから対応する
- 受注変動への対応が遅い／顧客への納期回答が後手
After — Formula導入後の業務状態
- 全プラント連動で数時間先まで予測される
- 需給逼迫の "前" に打ち手を選べる
- 意思決定の根拠が言語化・共有される
- 部門横断のトレードオフが議論可能になる
- 余裕運転が減り、エネルギー・原料が節約される
- 顧客への納期回答精度が上がる
Formulaでどう解決するか
既存システムを リプレイスしない。Formulaは「文脈の実装層」として上に乗り、既存資産を活かしながら意思決定の質を変える。
既存システム（DCS／ヒストリアン／ERP）はそのまま、データだけ連携
制御系には触らない。ヒストリアン経由で読み取り専用接続。お客様が長年育ててきた現行資産を一切壊さない。
ドメインモデリング ──「文脈の実装」
プラント・流量・生産比率・原料・製品・顧客需要を、お客様の業務言語で意味付けされたデータモデルに落とす。FDEが現場ヒアリングを行い、ドメイン知識をデータ構造として実装する。これがFormulaの本質。
物質収支ベースのシミュレーター
ML予測ではなく、まずは 物質収支に基づくルールベース でシミュレーターを実装。「電解出力をX%に下げた場合、塩素タンクは何時間後に何%になるか」を、業務担当者が説明できる仕組みで動かす。
意思決定UI ── 数字を「業務の言葉」で見せる
担当者が見るのは数式ではなく、「あと4時間でタンク満杯」「下流Aを止めると上流Bが2時間後に過剰生産」等のナラティブ。意思決定者の認知に合わせる。
narrow wedgeから段階展開
最初は1中間品の系統だけ（例：塩素1系統）→ 動くToBeで価値を実証 → 苛性ソーダ／水素／下流誘導品系へ横展開。一気に全プラント連動を狙わない。
想定される経済価値
案件化時にお客様と一緒にレンジを埋める。汎用ROI試算はせず、お客様の具体プロセスから逆算する。
直接的な価値
- 余裕運転（過剰生産・過剰在庫）削減によるエネルギー・原料コスト
- 需給逼迫時の機会損失削減（下流顧客への供給維持）
- 調整会議工数の削減
間接的な価値
- 顧客への納期回答精度の向上 → 顧客満足度・継続取引
- ベテラン退職リスクの緩和（暗黙知の言語化）
- 部門横断の意思決定文化の醸成
- 他プラント・他工場への横展開ベース
初回商談で聞くべきこと
最初の3〜5分で以下を聞き出せれば、このオファが当たるかどうかが判断できる。質問は 業務状態を聞く形 で。「製品紹介してもいいですか」とは絶対に言わない（D00 2026-04-08）。
禁句 — このオファでは絶対に言わない
- 「うちの製品を導入しませんか」
- 「DCSをリプレイスしましょう」
- 「AIで全部解決します」
- 「機械学習で需要予測します」（最初は物質収支から）
- 「全プラントを一気に連動させましょう」（narrow wedgeから）
想定される反論と切り返し
標準スコープと、別途見積りになるもの
標準スコープに含む
- 業務ヒアリング・ドメインモデリング
- データモデル設計（連産品の物質収支構造）
- ヒストリアン／ERPからのデータ連携（読み取り専用）
- 物質収支ベースのシミュレーター実装
- 意思決定UI（業務担当者向け）
- 初期1系統の動くToBe
- 運用基盤（Formula標準）
別途見積り
- DCS／制御系との直接接続（推奨しない）
- 安全系との連携
- 機械学習による需要予測モデル
- センサー新設・物理的な計測の追加
- 社内向けユーザー教育プログラム
- 2系統目以降の横展開（同オファ・別案件として再見積り）
なぜこのオファがPortXで勝てるか
A00 §7「narrow wedge」のど真ん中
「在庫」「生産調整」「需給調整が属人的で変動に弱い」をすべて含む。会社の勝ち筋に最も近いオファ。
顧客の課題認識とFormulaの強みが完全一致
顧客自身が「数学は難しくない、データ統合と文化が難しい」と認識している。Formulaの本質である「文脈の実装（ドメインモデリング）」と直接接続する。技術ではなく、構造で勝てる。
「動くToBe」が極めて作りやすい
1中間品のタンクシミュレーター画面1枚で、顧客は「自分の問題が解ける」と即座に理解する。営業段階で動くToBeを見せる戦術（A00 §8.3）と最も相性が良い。
複利化の起点になる
連産品プロセスを持つ業界は化学・素材・製鉄・製紙など複数。1社で深く作り込めば、ほぼそのまま横展開できるテンプレになる。A00 §8.5「複利化」を最も体現する候補。
「便利機能」ではなく「競争優位の実装」
連産品の需給逼迫時の意思決定品質は、その会社の収益性そのもの。A00 §5.3「競争優位そのものを実装する」と直結する。
参照接点
案件化・進行に応じて追記していく。匿名化を徹底すること。
このパックの更新ルール
- •新しい商談・案件で出てきた業務痛シグナル・反論・経済価値を、該当セクションに追記する
- •追記は 削除ではなく蓄積。過去のシグナルも残す（複利の器）
- •顧客固有名詞・固有数値は 必ず匿名化（「ある化学メーカーでは…」「典型的な連産品プロセスでは…」）
- •AE・FDE 双方が更新権限を持つ。AEはダイアログ・反論セクション、FDEはドメインモデリング・スコープセクションを主に
- •大きな構造変更（新セクション追加・削除）は CEO レビュー後