FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務

前回の記事「EDIとは？企業間の受発注をどう楽にするのか」では、FAXやメールで受け取った注文を人が入力し直す業務を、システム間のデータ交換へ置き換える仕組みを整理しました。

この記事はその続編です。テーマは「仕組みの理解」から一歩進めて、どう移行するかです。

「FAX受注をWeb化したい」という相談は、多くの場合こう続きます。

「ただし、取引先にはFAXしか使えないところもある」

「販売管理システムは今のまま使いたい」

「切り替えの間、受注が止まるのは困る」

つまり実務上の課題は、Web受注システムを作ることではありません。FAXが残ったまま、Webへ段階的に移していく期間をどう設計するかです。

この記事では、FAX受注のWeb化を、二重運用期間の設計、CSV取込という中間形態、商品・取引先マスタの整備、取引先の巻き込み方の4点を中心に整理します。

1．まず結論

FAX受注のWeb化を計画するときの要点は、次のとおりです。

• 目標を「FAXの廃止」ではなく、「人が入力する注文の件数を減らすこと」に置く
• FAXとWebの二重運用期間は必ず発生する前提で、期間と測り方を先に設計する
• 受付方法(チャネル)は複数でも、社内の受注処理は1本にまとめる
• いきなりWeb画面入力を求めず、CSV取込という中間形態を用意する
• Web受注の画面には商品・取引先マスタがそのまま表に出るため、マスタ整備を先に行う
• 取引先は一斉に切り替えず、件数と協力度で分類して順番に移行する

JIPDECも、FAXや電話などの人手処理が残ると、その対応要員が必要になり、効率化の効果を十分に得にくいと指摘しています。だからこそ、二重運用期間を「仕方なく発生するもの」として放置するのではなく、短くしていく計画そのものを設計の対象にします。

2．いきなり全面Web化が失敗しやすい理由

FAX受注のWeb化には、社内システムの都合だけでは決められない特徴があります。注文を送るのは取引先だからです。

全取引先に対して「来月からWebで注文してください」と案内する方式は、次のような失敗につながりやすくなります。

• FAXでしか注文できない取引先が「例外」ではなく「計画の障害」になる
• 取引先ごとに事情が異なるのに、同じ締め切りを課してしまう
• 移行しない取引先の注文が結局FAXで届き続け、二重運用が無期限化する
• 「Web化したのに人が減らない」という評価になり、プロジェクトが止まる

原因は、目標を「FAXをなくすこと」に置いていることです。

目標を「人が入力する注文の件数を減らすこと」に置き換えると、計画は現実的になります。例えば、注文の7割を占める上位の取引先だけがWebやCSVへ移行すれば、残り3割がFAXのままでも、入力作業は大きく減ります。

全体を一度に動かすのではなく、効果の大きいところから順に動かす。これが段階移行の基本です。

3．移行後の姿 ── 入口は複数、社内処理は1本

段階移行を設計する前に、目指す形を先に描いておきます。

ポイントは、受付チャネルと受注処理を分けて考えることです。

[受付チャネル]                 [共通の受注データ]        [社内処理]

FAX ──── 担当者が入力 ──┐
メール添付 ── 担当者が入力 ─┤
CSV取込 ─── 自動取込 ────┼──→ 受注データ ──→ 在庫引当・出荷・請求
Web受注画面 ── 自動登録 ───┘      (形式を統一)

受付チャネルが何種類あっても、その先の受注データの形式と処理を1本にまとめておけば、在庫、出荷、請求などの後工程は共通のまま動きます。

逆に、チャネルごとに別の処理や別の台帳を作ってしまうと、チャネルが増えるたびに業務が複雑になり、二重運用の負担が増え続けます。

FAXで届いた注文も、担当者が入力した時点で他のチャネルと同じ受注データになるようにします。移行とは、この図の中で「担当者が入力」の行に流れる件数を減らし、「自動取込」「自動登録」の行に流れる件数を増やしていく作業だと言えます。

既存の販売管理システムを刷新する必要は、必ずしもありません。受注データの入口を追加できるか(CSV取込機能、データベース連携、APIなど)が確認できれば、今の仕組みを残したまま進められます。この確認ポイントは前回のEDI記事の「社内システムへの接続を確認する」で整理したとおりです。

4．CSV取込という中間形態

FAXからいきなりWeb画面入力へ移ってもらうのは、取引先にとって負担が大きいことがあります。

発注する側から見ると、Web画面入力とは「自社の発注システムやExcelで作った注文を、もう一度相手の画面に入力すること」だからです。取引先が自社の仕組みで注文データを作っているなら、そのデータをファイルのまま受け取って取り込む方が、双方の作業が少なくて済みます。

そこで中間形態として、CSV(またはExcel)取込を用意します。

第1段階: CSVをメールに添付して受け取り、担当者が取込機能で読み込む
第2段階: 取引先がWebページからCSVをアップロードし、自動で取り込む
第3段階: 定型化した取引先はWeb受注画面またはEDIへ

第1段階でも、注文書を見ながらの手入力に比べれば、入力時間と転記ミスは大きく減ります。取引先側の変化は「FAXで送っていたものをメール添付に変える」程度で済むため、協力を得やすいのも利点です。

CSV取込を設計するときは、最低限、次の項目を決めます。

CSVは単純に見えて、文字コード、改行、カンマや引用符の扱いなどで落とし穴の多い形式です。取込処理を実装する際の技術的な注意点は「CSVファイル処理の実務ガイド」にまとめています。

なお、CSV取込は最終形ではなく中間形態です。ここで決めた項目定義とコード体系は、その後のWeb受注やEDIでもそのまま土台になります。

5．商品・取引先マスタの整備を先に行う

FAX受注では、マスタの不備は担当者が吸収しています。

例えば、注文書に古い商品名が書かれていても、担当者が「これは現行のこの商品のこと」と読み替えて入力しています。単位が「ケース」で書かれていても、1ケースが何個入りかを覚えていて換算しています。

CSV取込やWeb受注に移ると、この読み替えを機械が行うことになります。さらにWeb受注画面では、商品マスタがそのまま取引先の目に触れます。

そのため、移行の前に少なくとも次の整備が必要です。

• 商品コードの整理(廃番の整理、重複の統合、新旧コードの対応表)
• 商品名の表記統一(取引先に見せられる名称になっているか)
• 単位と入数(バラ・ケース・パレットの関係、最低注文数量)
• 取引先コードと納品先コード(1取引先に複数の納品先がある場合の扱い)
• 取引先別の適用単価や契約条件をどこで管理するか

ここで重要なのは、全マスタを完璧にしてから始めようとしないことです。それを待つと移行が始まりません。

現実的なのは、最初に移行する取引先(パイロット)が扱う商品と納品先の範囲だけを先に整備し、移行する取引先を増やすたびに範囲を広げる方法です。マスタ整備の作業自体を、段階移行のフェーズに組み込みます。

6．二重運用期間の設計

FAXとWeb(CSV)の二重運用は、移行期間中は必ず発生します。設計せずに放置すると、二重運用が常態化し、「チャネルが増えた分だけ仕事が増えた」状態になります。

二重運用期間の設計とは、具体的には次を決めることです。

6.1．期間と目標値を決める

「いつまでに、注文件数の何割を自動取込にするか」を数値で決めます。例えば「6か月でFAX受注の比率を70%から30%へ」のような形です。

期限のない二重運用は、そのまま固定化します。到達できなかった場合も、期限があれば「なぜ移行が進まないのか」を取引先ごとに確認する行動につながります。

6.2．チャネル別の件数を毎月測る

移行の進み具合は、感覚ではなく件数で追います。

• チャネル別の受注件数(FAX、メール添付、CSV、Web)
• 手入力した注文の件数と所要時間
• 取込エラーの件数と原因
• 入力訂正・二重登録の件数

前回の記事で挙げた導入後に測りたい指標と同じ考え方です。チャネル別に分けて測ることで、「どの取引先に働きかければ効果が大きいか」が見えます。

6.3．運用ルールをチャネル間でそろえる

二重運用期間中に混乱が起きやすいのは、チャネルによって業務ルールが違う場合です。

• 受注の締め時刻はFAXとWebで同じか
• 注文変更・取消はどのチャネルで受けるか(Webで受けた注文の変更をFAXで受けると、突合が必要になる)
• 欠品時の連絡方法はチャネルで変わらないか
• 注文番号はチャネルをまたいで一意か(二重登録の検出に必要)

特に「Webで注文し、直後に電話やFAXで変更する」パターンは必ず発生します。変更をどのチャネルで受け、誰がどのデータを直すのかを先に決めておきます。

6.4．FAXの受け方も改善対象にする

二重運用期間中、FAXは残ります。残る前提なら、FAX側の処理も改善の対象です。

• FAXを複合機で受けてPDF化し、紙の管理をやめる
• 受信したPDFを受注フォルダーに集約し、処理状況(未処理・入力済み・保留)を管理する
• 入力後のFAX原本(PDF)と受注データを注文番号で紐づけ、あとから照合できるようにする

「FAXはいずれなくなるから手を付けない」と考えると、二重運用期間中の負担が下がりません。移行が完了するまでの間、FAX処理も同じ受注データに合流する一つのチャネルとして扱います。

7．取引先の巻き込み方

段階移行の成否は、社内よりも取引先への働きかけで決まります。

7.1．取引先を分類する

全取引先を同じように扱わず、まず分類します。

効果を決めるのはAとBです。Cの取引先を無理に動かそうとするとコストばかりかかるため、「FAXも受け続けます」と明言してよい相手です。

7.2．パイロットを1社選ぶ

最初から複数社を並行して移行せず、まず1社で運用を確立します。選ぶ基準は前回の記事と同じです。

• 取引件数が多く、効果を測定しやすい
• 定型的な注文が多い
• 担当者同士の連絡が取りやすく、システム連携への理解がある

パイロットで、CSVフォーマット、エラー時の連絡方法、マスタの対応表、案内文書などの「型」を作り、2社目以降はその型を再利用します。

7.3．相手のメリットで案内する

取引先から見ると、注文方法の変更は自社都合の依頼です。案内は自社の効率化ではなく、相手のメリットで説明します。

• 受注確認がすぐ返るため、「届いたかどうか」の確認電話が不要になる
• 読み間違いによる誤出荷・数量違いが減る
• 注文履歴を自分で参照でき、繰り返し注文が楽になる(Web受注の場合)
• FAXの送信作業と送信エラーの再送がなくなる

あわせて、実務的な配慮も効果があります。

• 操作手順は1枚のマニュアルにまとめる(画面数枚の操作説明で足りる規模にする)
• 開始日と併用期間を明示する(「◯月からWebでも受け付けます。FAXも当面併用できます」)
• 最初の数回は、FAXとWebのどちらで送られても受け付け、問い合わせに即応する

なお、「FAXを◯月で廃止します」という案内を最初に出すのは勧めません。移行が進み、残る取引先が少数になった段階で初めて期限の話をする方が、関係を損ねずに済みます。

中小企業の受発注デジタル化については、中小企業庁が共通EDIを含む標準化の取り組みや効果を紹介しています。業界団体や主要取引先がこうした標準に対応している場合は、独自形式ではなく標準に合わせる選択肢も検討します。

8．段階移行のモデルケース

ここまでの内容を、時系列のモデルに整理します。期間はあくまで一例で、取引先数と社内体制によって変わります。

フェーズ0の「現状整理」は、前回の記事で紹介した受発注方法の一覧化がそのまま使えます。

また、受注管理そのものをWebシステムへ移すべきかどうか、デスクトップアプリのまま残すべきかで迷う場合は、「WindowsアプリをWebに移すべきか」で判断の枠組みを整理しています。受付チャネルのWeb化と、社内システムのWeb化は、切り離して判断できます。

9．よくあるつまずきと対策

最後に、実際の移行で起きやすいつまずきをまとめます。

まとめ

FAX受注のWeb化は、システムを作る作業というより、移行期間を設計する作業です。

• 目標は「FAXの廃止」ではなく「人が入力する注文件数の削減」に置く
• 受付チャネルは複数あってよいが、社内の受注データと処理は1本にまとめる
• いきなりWeb画面入力を求めず、CSV取込という中間形態を挟む
• マスタ整備は、最初に移行する取引先の範囲から段階的に進める
• 二重運用期間には期限と目標値を設け、チャネル別の件数で進捗を測る
• 取引先は件数と協力度で分類し、パイロット1社で型を作ってから広げる

前回の記事で整理したとおり、EDIやWeb受注の効果は、受け取ったデータを社内業務のどこまで流せるかで決まります。移行の設計とは、その流れに合流する注文の割合を、無理のない順番で増やしていく計画のことです。

受発注のWeb化をご検討の方へ

FAX受注の見直しを検討しているものの、取引先との調整、既存の販売管理システムとの接続、CSVフォーマットやマスタ整備の進め方など、どこから手を付けるべきか迷う場合は、まず現状のチャネル別受注件数の整理から始める必要があります。

合同会社小村ソフトでは、既存のWindows業務アプリやデータベースを活かしたCSV取込・Web受注連携の設計・実装、および移行計画そのものの整理をご相談いただけます。

全面刷新を前提にせず、現在の販売管理の仕組みを残しながら、受付チャネルだけを段階的に追加していく構成も検討できます。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。