先日、OpenAIのブログでChocoという食品流通スタートアップの事例を読んだ。
Chocoは飲食店と食品卸業者をつなぐプラットフォームで、AIエージェントを使って受発注業務を自動化した会社だ。
この事例、製造業の営業DXとは直接関係ない話なのだが、妙に刺さるものがあった。
Chocoが解決しようとしていた課題は、電話やFAXで飛び交う膨大な注文データの処理だった。
レストランからの注文は「今日はトマト20kg、あとキュウリも」みたいな非構造化データばかりで、それを人手で入力・照合していた。
OpenAI APIを使ったAIエージェントを導入することで、この処理を大幅に自動化し、担当者の生産性が劇的に向上したという。
読んでいて一番気になったのは、成果の見せ方だ。
Choco側は「担当者が繰り返し作業から解放され、より付加価値の高い業務に集中できるようになった」と説明している。
これ、経営陣へのプレゼンで使える言い方かというと、正直微妙だと思う。
自分の会社でもAIツール導入の稟議を何度か通してきたが、「生産性向上」という言葉だけでは通らない。
役員会では必ず「で、何人分の工数が削減できるんだ」と返ってくる。
Chocoの事例には具体的な削減工数の数値は出ていなかったが、「処理速度の大幅な改善」「成長余力の確保」という切り口で語られていた。
これは要するに、「増員なしで事業拡大できる」という話だ。
製造業の営業DXに置き換えると、この言い方はかなり使えると思った。
「AIで見積もり作成の工数を〇時間削減できる」より「同じ人数で1.3倍の案件を処理できる体制になる」の方が、経営陣には刺さりやすい。
攻めの投資として見せられるからだ。
もう一つ気になったのが、ChocoがOpenAI APIを直接使って自社開発した点だ。
パッケージ製品ではなく、APIを使って自分たちの業務フローに合わせて作り込んでいる。
これ、うちの部署でも同じ選択肢があるわけで、改めて「既製品か自社開発か」という判断軸を考え直すきっかけになった。
ベンダー提案を評価するとき、自分は最近こういう視点で見るようにしている。
Chocoの事例は「APIを直接使った自社開発」のため、カスタマイズ性は高い反面、うちのような大手製造業がそのまま真似するのは難しい。
社内のセキュリティ審査だけで数ヶ月かかるし、開発を担える人材が社内にいるかという問題もある。
ただ、「どんな課題をどのロジックで解いたか」という設計思想は参考になる。
ChocoのAIエージェントが非構造化データを処理してワークフローに組み込む仕組みは、営業部門が日々扱うメールや商談メモの処理と構造的に似ている。
FAXの注文書を読み取るのと、営業担当が送ってくる日報を解析するのは、課題の本質が同じだ。
今週、部下の一人が「営業日報の自動要約ツール」を試したいと言ってきた。
Chocoの事例を頭に入れながら、そのツールの提案内容をもう一度読み直してみるつもりだ。
「この仕組みで、何人分の増員を回避できるか」を自分なりに試算してから、次の定例会議に持ち込もうと思っている。
Chocoは飲食店と食品卸業者をつなぐプラットフォームで、AIエージェントを使って受発注業務を自動化した会社だ。
この事例、製造業の営業DXとは直接関係ない話なのだが、妙に刺さるものがあった。
Chocoが解決しようとしていた課題は、電話やFAXで飛び交う膨大な注文データの処理だった。
レストランからの注文は「今日はトマト20kg、あとキュウリも」みたいな非構造化データばかりで、それを人手で入力・照合していた。
OpenAI APIを使ったAIエージェントを導入することで、この処理を大幅に自動化し、担当者の生産性が劇的に向上したという。
「生産性向上」を経営陣にどう数字で見せるか
読んでいて一番気になったのは、成果の見せ方だ。
Choco側は「担当者が繰り返し作業から解放され、より付加価値の高い業務に集中できるようになった」と説明している。
これ、経営陣へのプレゼンで使える言い方かというと、正直微妙だと思う。
自分の会社でもAIツール導入の稟議を何度か通してきたが、「生産性向上」という言葉だけでは通らない。
役員会では必ず「で、何人分の工数が削減できるんだ」と返ってくる。
Chocoの事例には具体的な削減工数の数値は出ていなかったが、「処理速度の大幅な改善」「成長余力の確保」という切り口で語られていた。
これは要するに、「増員なしで事業拡大できる」という話だ。
製造業の営業DXに置き換えると、この言い方はかなり使えると思った。
「AIで見積もり作成の工数を〇時間削減できる」より「同じ人数で1.3倍の案件を処理できる体制になる」の方が、経営陣には刺さりやすい。
攻めの投資として見せられるからだ。
ベンダー提案を評価するときに見るべきポイント
もう一つ気になったのが、ChocoがOpenAI APIを直接使って自社開発した点だ。
パッケージ製品ではなく、APIを使って自分たちの業務フローに合わせて作り込んでいる。
これ、うちの部署でも同じ選択肢があるわけで、改めて「既製品か自社開発か」という判断軸を考え直すきっかけになった。
ベンダー提案を評価するとき、自分は最近こういう視点で見るようにしている。
- 自社の業務データを学習・処理する範囲がどこまでか(セキュリティ要件の確認)
- カスタマイズの自由度と、それに伴う開発コスト・保守コスト
- 導入後の効果測定を自分たちで行える設計になっているか
Chocoの事例は「APIを直接使った自社開発」のため、カスタマイズ性は高い反面、うちのような大手製造業がそのまま真似するのは難しい。
社内のセキュリティ審査だけで数ヶ月かかるし、開発を担える人材が社内にいるかという問題もある。
ただ、「どんな課題をどのロジックで解いたか」という設計思想は参考になる。
ChocoのAIエージェントが非構造化データを処理してワークフローに組み込む仕組みは、営業部門が日々扱うメールや商談メモの処理と構造的に似ている。
FAXの注文書を読み取るのと、営業担当が送ってくる日報を解析するのは、課題の本質が同じだ。
今週、部下の一人が「営業日報の自動要約ツール」を試したいと言ってきた。
Chocoの事例を頭に入れながら、そのツールの提案内容をもう一度読み直してみるつもりだ。
「この仕組みで、何人分の増員を回避できるか」を自分なりに試算してから、次の定例会議に持ち込もうと思っている。