FAXで注文を受けている建材商社が、Web受発注に移行するときに知っておくべきこと

受発注をFAXでやっている。今もそれで回っている。でも、どこかでこのままではまずいと感じている。そんな担当者に向けて書きます。

「Webで完結させたい」の中身を整理する

「受発注をWeb化したい」という言葉は、実はかなり多くのことを含んでいます。

顧客がシステムにログインして直接注文を入力できるようにしたい。でも全員がそうしてくれるわけではなく、慣れている取引先はFAXで送ってきます。だからFAXで届いた注文書もシステムに取り込みたい。受注したら今度はメーカーに発注しなければなりません。発注先が200社ほどあるケースも珍しくありません。それが完了したら、ゆくゆくは基幹システムに自動で連携させたい。

これを一つひとつバラバラのシステムで対応しようとすると、結局つなぎ目で手作業が発生します。転記ゼロを目指して導入したのに、別の場所で転記が生まれる。これは建材商社に限らず、受発注Web化プロジェクトが「思っていたよりも楽にならなかった」と感じる最大の理由です。

顧客数が多いほど、Web化の難易度は上がる

全国に多数の顧客を抱える商社では、全員を同じ操作に統一するのは現実的ではありません。

スマートフォンで注文する取引先もいれば、タブレットを使う取引先もいる。PCの方もいる。中には「FAXじゃないと不安」という取引先も一定数いるはずです。

だから考えるべきは「全員をWeb化する」ではなく「どのチャネルで来た注文でも、社内での処理は一元化できる仕組みを持つ」ことです。顧客がどんな手段で注文してきても、受け取る側は同じ画面で確認できる。FAXで来た注文はAI-OCRが自動でデータ化する。Webから来た注文はそのままシステムに入る。社内の担当者が数十名規模であれば、この一元化の効果は特に大きくなります。

AI-OCRに期待しすぎてはいけない、でも使わないと損をする

AI-OCRは「FAXの注文書を自動でデータ化してくれる」技術です。ただし、精度には差があります。

一般的なAI-OCRの判読率は8割程度と言われています。残りは手入力になります。建材の注文書は品番が英数字混じりで長かったり、手書きで数量が書き加えられていたりします。この「手書きと活字の混在」が、精度を下げる主な原因になります。

判読率を上げるために重要なのは、「この取引先はこのフォーマットで注文書を送ってくる」という事前情報をシステムに持たせることです。取引先ごとにプロンプトを設定できる仕組みがあると、同じAI-OCR技術を使っていても精度が大きく変わります。

100%の自動化を目指すのではなく、「取り込んだデータを確認して修正するだけ」という状態にすることが現実的な目標になります。ゼロから手入力するのと、ほぼ完成したデータを確認するのとでは、工数がまったく異なります。

メーカーへの発注をどう処理するか

受注を受けたあと、メーカーへの発注が発生します。発注先が多数あるというのは、なかなか複雑な状況です。

メーカー側がシステムに対応していればEDI連携が使えます。対応していなければ、発注書をPDFで生成してメール添付するか、CSVで吐き出して送るという運用になります。いずれにしても「受注データをそのまま発注に使える」設計になっているかどうかが重要で、受注データを別途コピーして発注書を作るという作業が残ると、そこにミスが生まれます。

受注から発注まで、同じデータが引き継がれる仕組みになっているかを、システム選定の段階で確認しておく価値があります。

基幹システムとの連携は後回しにしていい、でも設計には入れておく

大塚商会のSMILE Vのような中堅・中小向けの基幹システムは、建材業界でも広く使われています。

ただし、受発注システムと基幹システムの連携は、最初から完全に自動化しようとすると、そこに工数とコストが集中してしまうことが多くあります。段階的に進めるほうが現実的です。

最初はCSV出力して手動でインポートする運用でもよい。大事なのは「将来的に連携できる設計になっているか」であって、「今すぐ連携していること」ではありません。APIが公開されているか、CSV連携の仕様が明確か、この2点を確認しておけば、後から自動化の選択肢が残ります。

機能を絞ることへの正しい解釈

「不要な機能を省いてシンプルに、費用を抑えたい」というのは、多くの企業が希望することです。ただ、ここで注意したいのは、シンプルにすることと、必要な機能を削ることは別だということです。

受注管理、顧客ログイン機能、AI-OCR、発注管理。これらがMustで必要だと整理されているなら、この4つがちゃんと連動していれば、他の機能はなくてもいい。シフト管理や不動産管理といった、建材商社の受発注業務に直接関係のない機能は、最初から省いて構いません。

シンプルな構成にするためには「何を使わないか」を最初に決めることが重要で、機能ごとに追加できるモジュール型の料金体系であれば、必要なものだけを選べます。

Wikiだるまが建材商社に合う理由

Wikiだるまは、卸売・商社向けに設計されたAI受発注システムです。

基本プランにFAX-OCRと三者間受発注管理が含まれており、在庫管理や請求管理は追加オプションで選択できます。取引先ごとにプロンプトを設定できるため、判読率が最大99%まで上がると公表しています。顧客側のアカウント料金は発生しない設計になっており、これは顧客規模が大きい商社ほど、コスト面で重要な点になります。

初期費用はゼロで、月額6万円から始められます。2週間のトライアルがあるため、実際の注文書で精度を確認してから判断できます。

基幹システムとの連携については、CSV・EDI・API連携が標準対応と公開されていますが、個別のシステム固有の仕様への対応状況は商談で直接確認することをおすすめします。

情報収集段階でやっておくべきこと

まだ導入を決めていない段階であれば、デモを見ることよりも先に、自社の注文書のパターンを整理しておくことが有効です。

取引先によって注文書のフォーマットが違うはずです。手書きが多い取引先、活字だけの取引先、電話で来る取引先。これを把握しておくと、システム選定のときに「このフォーマットは読み取れますか」という具体的な確認ができます。

社内ユーザーが実際にどの業務で使うかも整理しておくと、デモのときに聞くべき質問が変わります。担当者が変わっても業務が止まらない仕組みになっているか、権限設定はどこまでできるか。こうした点は、実際に使い始めてから問題になりやすい部分です。

まとめ

FAX受発注の現場からWeb化に向かうとき、一番コストがかかるのは「システム間のつなぎ目」です。そこを最初から設計に入れておくかどうかで、1年後の状況がかなり変わります。