株式会社etika ご提案

FLAM から Zoho へ移行
販売フロント強化 × BtoB受発注のEC化｜株式会社メイクス 様

作成 株式会社etika 作成日 2026-06-02 対象事業 美濃焼産地の陶磁器・ガラス企画卸／OEM
FLAM→Zoho（CRM／Inventory）＋ Bカート

0. 前提

本提案は、現行の販売管理システム FLAM から Zoho へ移行することを前提とします。
FLAM現行の販売管理システム（在庫・受注事務／見積〜入金）
Bカート（Bcart）BtoB EC・Web受発注の基盤
メールマーケティングZoho CRM ＋ Zoho Campaigns ＋ Zoho SalesIQ
移行先の基幹Zoho Inventory ＋ Zoho CRM（Books不使用）
会計マネーフォワード等クラウド会計に連携
初期データ移行主にFLAMのCSVエクスポート（顧客・取引先・商品・履歴）で実施

1. 背景（現状）

結論：FLAMは「見積以降〜入金」に最適化される一方、前後（リード〜商談〜マーケ、サポート〜分析）とEC・拡張性が構造的に不足。EC進出・増員の今こそ、前後工程まで1つに通せる Zoho へ移行し、同時にBtoB受発注をBカートでEC化するのが最善です。

2. なぜ FLAM から Zoho へ移行するのか（4つの強み）

移行価値は、FLAMが担えない領域を Zoho が一気通貫でカバーできる点にあります。

1適用範囲の広さ
Zoho：販売管理の前後工程（リード獲得→マーケ→商談→受注→納品→請求→サポート→分析）を1ベンダーで通せる
FLAM：「見積以降〜入金」に限定。営業プロセス可視化・マーケ・顧客サポートは守備範囲外
2カスタマイズ性と拡張性
Zoho：業務に合わせて作り込める。将来のEC連携（Bカート等）も視野
FLAM：カスタムフィールド・アクセス権限など軽微な設定中心で、業務フロー自体は固定
3AI／自動化の余地
Zoho：Zia、Vertex AI連携、Slack/Google Chat連携など、AIを乗せた業務自動化へ発展しやすい
FLAM：AI・自動化の発展余地が乏しい
4CRM起点の営業管理
Zoho：見込み客・商談フェーズ・パイプライン・行動履歴を管理。営業の入口から可視化
FLAM：「受注が決まった後の事務処理」が出発点で、商談管理は守備範囲外
まとめ：メイクス様がこれから伸ばす ①営業フロント ②マーケ ③EC ④サポート・分析・AI はいずれもFLAMの守備範囲外。Zohoはこの4領域を“業務に合わせて作り込み・1ベンダーで”実現でき、移行価値が大きいと考えます。

3. ご提案の全体像（FLAM → Zoho 移行）

共通の狙い

  1. 販売フロントの強化（見込み客の獲得と“シグナル”取得） … 名刺の見込み客〜既存顧客を Zoho CRM に集約 → Zoho Campaigns で新商品・他社企画・在庫情報を告知 → Zoho SalesIQ でメール開封・クリックや自社サイト・Bカートの閲覧といった反応（シグナル）を取得し「いま関心が高い取引先」を可視化 → 営業がすぐフォロー → Bカート（BtoB EC）へ集客。
  2. BtoB受発注のEC化 … 電話／FAX／メール受発注を Bカート に置換、受注を移行後のZoho基幹へ連携。
  3. 基幹の移行 … FLAMの在庫・受発注をZohoへ移し、安定後にFLAM解約。会計はマネーフォワード等へ連携。
メールマーケ＋シグナルのメリット：FLAMには無い「見込み客への一斉告知」と「誰が反応したか」の把握を、Zoho CRM × Campaigns × SalesIQ で実現。配信しっぱなしでなく、反応＝商機のサインを拾って動けるのが強みです。

移行先の2パターン（在庫管理の複雑性 × Zoho Inventory要件の合致性で選ぶ）

判断軸2-A（Zoho Inventory）が向く2-B（CRMカスタム）が向く
在庫管理の複雑性倉庫/ロケーション複数、ロット・在庫引当、入出荷が多い在庫を多く持たず受注都度メーカー手配中心、入出荷が軽い
Inventory標準要件との合致標準機能（受注SO/発注PO/在庫/出荷）で大半が賄える検品(はますり)・OEM個別仕様など特殊フローが標準に乗りにくい
コスト/作り込みライセンス追加でも標準機能を使う方が早いCRM内カスタムで製品数を絞り費用を抑えたい
分岐の決め方：ファブレスで「在庫をどこまで持つか」が分岐点。まず現行の受発注・在庫・検品フローを棚卸しして2-A/2-Bを確定します。

案2-A Zoho Inventory 採用

名刺・問い合わせ・展示会
↓
Zoho CRM（見込み客・顧客・商談）
↓ Campaigns告知 ＋ SalesIQでシグナル取得
Bカート（BtoB EC：取引先がWeb発注）
↓ 受注 (orders-read / Webhook)
Zoho Inventory（受注SO・発注PO・在庫・出荷）
← FLAM置換
↓ 売上・請求データ
マネーフォワード等 クラウド会計
在庫・商品：Zoho Inventory → Bカート（product_stock-write / CSV）

✅ メリット

  • 在庫・受発注の標準機能が厚い（複数倉庫・引当・SO/PO）
  • 複雑な在庫に強い／CRMと標準統合

⚠️ 留意点

  • ライセンス費用が増える
  • 特殊フロー（検品・OEM）は調整 or 一部カスタム

案2-B Zoho CRM カスタムで代替

名刺・問い合わせ・展示会
↓
Zoho CRM
見込み客・顧客・商談（標準）
＋カスタムM（商品/受発注/簡易在庫）
↓ Campaigns告知 ＋ SalesIQでシグナル取得
Bカート（BtoB EC）
↓ 受注 (orders-read / Webhook)
Zoho CRM カスタムへ統合
← FLAM置換
↓ 売上・請求データ
マネーフォワード等 クラウド会計
在庫・商品：CRMカスタム → Bカート（product_stock-write / CSV）

✅ メリット

  • 1製品（CRM）に集約しライセンス抑制
  • 業務に完全フィット／在庫が軽いファブレスなら十分

⚠️ 留意点

  • ロット・複数倉庫・自動引当など高度な在庫は自前カスタムで限界
  • 作り込み・保守の負荷
案2 共通：顧客〜受発注〜在庫が1つの土台に乗り二重入力・マスタ分散が解消。FLAM解約でランニング集約。一方、Zohoへの移行負荷・教育コスト、並行運用・データ移行、会計(MF等)連携設計が必要です。

4. データ × AIエージェントによる分析・商品開発（発展）

Zohoへ移行すると、顧客・商談・受注・在庫・EC上の行動（メール反応やサイト来訪）といった全体データが1つの土台に集約されます。この一元データを AIエージェント（Zoho Zia／Vertex AI連携 等）に読み込ませることで、人手では追いきれない分析と気づきを自動化できます。

取引先ごとの受注傾向の分析
どの取引先が・いつ・何を・どれくらい発注するか。発注の山谷や離反の兆候を把握。
商談の発生元（流入元）の特定
受注・商談が「メール告知／Bカート／展示会／紹介」などどこから生まれたかを可視化し、効く施策に集中。
商品の購入傾向の推移
カテゴリ・素材・価格帯・季節での売れ筋の動きを時系列で把握。
商品開発のヒント
上記を束ね、「次に伸びそうな組み合わせ・価格帯・投入時期」をAIが提案。企画力をデータで裏づけ・加速。
これは「顧客〜受発注〜在庫〜EC行動」がZohoに集約されて初めて効きます。FLAMのように領域が分断されていると横断分析は困難です。移行は、AI活用の土台づくりでもあります。

5. 比較（案2-A / 案2-B）

観点案2-A（Zoho Inventory）案2-B（Zoho CRMカスタム）
基幹（在庫・受注事務）Zoho InventoryZoho CRMカスタム
在庫管理の高度さ高（標準機能厚い）中（カスタム範囲）
業務フィット標準に寄せる完全フィットしやすい
ライセンス費用中〜大中
作り込み・保守少なめ（標準活用）多め（カスタム）
拡張性（EC本格化・分析・AI）高中〜高
向くケース在庫が複雑・入出荷が多い在庫が軽い・受注都度手配中心

いずれも FLAM解約・前後工程の一元化 は共通。違いは在庫の持ち方に対する基幹の作り方です。

6. 連携の実現性（Bカート API 調査結果）

出典：Bカート公式（機能一覧・外部連携・APIドキュメント V1）、各連携ベンダー資料（2026-06-02 時点）。

Bカート API の基本仕様

各連携ポイントの可否（移行後＝Zoho基幹を前提）

連携必要機能実現性補足
Bカート受注 → Zohoorders-read＋order_products-read＋Webhook(β)◎ 可能Webhook起点でAPI取得→Zohoへ投入
Zoho → Bカート（在庫反映）product_stock-write / 在庫CSV◎ 可能リアルタイムはAPI、日次はCSV
Zoho → Bカート（商品マスタ）商品API / 商品CSV○ 可能初期一括はCSV、差分はAPI
Zoho顧客 ⇔ Bカート会員会員API＋カスタム項目10○ 可能ZohoのIDを会員カスタム項目に保持し名寄せ
Zoho ⇔ Bカート 接続方式Zoho Flow / Deluge / CData / ASTERIA○ 可能公式専用コネクタは無いがREST APIで連携可
Zoho/Bカート → 会計(MF等)MFクラウド会計API / CSV○ 可能(要設計)売上・請求データを連携
FLAM → Zoho（初期データ移行）FLAMのCSVエクスポート○ 可能顧客・取引先・商品・履歴をCSV移行（API非公開でも可）
移行後（Zoho一元）の技術的実現性は高く、Bカート⇔Zoho はAPI/iPaaSで実現可能です。残る確認点は、Zoho Inventoryのフロー適合（2-A/2-B分岐）、会計(MF等)連携、FLAMのCSV出力項目。Webhookはβ版のため本番ではAPIポーリング併用も検討、レート制限（300req/300s）は通常運用に十分で、初期一括同期・データ移行は分割・夜間バッチで対応します。

7. 移行ロードマップ

  1. フェーズ0：要件確認（2〜3週） … 受発注・在庫・検品フローの棚卸しで案2-A/2-Bを確定、FLAMのCSV出力項目、Bカート契約プラン、会計(MF等)連携要件、EC対象範囲を確定。
  2. フェーズ1：フロント立ち上げ（1〜2か月） … Zoho CRMに見込み客・顧客を集約（名刺取り込み・FLAM顧客CSV移行）、Zoho Campaigns＋SalesIQでメール告知とシグナル取得を開始。増員する営業の受け皿に。
  3. フェーズ2：Bカート公開（2〜3か月） … 既存取引先のWeb発注を開始、メール→Bカート集客導線を接続、商品・在庫を連携。
  4. フェーズ3：基幹移行・並行運用（2〜3か月） … 受発注・在庫を Zoho（2-A/2-B）へ移行、Bカート受注を統合。FLAMと並行運用で検証。
  5. フェーズ4：FLAM解約・会計連携／AI分析の開始 … 運用が安定後にFLAMを解約、会計はMF等へ連携。蓄積データをAIエージェント分析へ展開。

増員フェーズに合わせ、新しい営業の業務を最初からZoho/Bカート前提で設計すると属人化を作らずに移行できます。

8. 費用・補助金（イメージ）

9. 確認させていただきたい事項 と 次のステップ

確認させていただきたい事項

次のステップ

  1. 本提案のレビュー（移行方針・4つの強み・シグナル取得／AI活用・2-A/2-Bの分岐観点）。
  2. FLAMのCSV出力、Bカート契約プラン、会計連携要件の確認。
  3. 受発注・在庫フローの棚卸し → 案2-A/2-Bを確定 → 要件定義 → 正式見積 → PoC・移行計画。

補足：FLAMを残す選択肢（参考）

移行を前提としていますが、もしFLAMを当面残す必要がある場合は、FLAM維持＋Zohoフロント＋Bカートを連携でつなぐ併存型も技術的には可能です（Bカート受注→FLAM、Zoho⇔FLAM顧客連携）。ただしFLAMのAPIが非公開のためCSV/バッチ連携となりリアルタイム性に制約があり、連携先も3システムに増えるため、今回は移行（Zoho一元化）を推奨します。