まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

Web受発注システム導入の進め方|替えるべきかの判断から取引先との併存・費用の見積もりまで

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • Web受発注で減らせるのは注文の受け渡し・転記・確認の手間で、価格の決め方や在庫の課題は残る
  • 製品を比べる前に、注文の流れ(誰が・何を・どの手段で・どれだけ)と例外の頻度を棚卸しする
  • 取引先は一部から移行し、Web注文の比率・問い合わせ・例外注文の件数を見てFAXや電話の受付を縮小する
  • 注文データは電子取引に当たりうるため、保存の仕組みを提供元に確認し、適用は国税庁の資料と税理士などで確かめる
  • 費用は初期費用・月額・オプション・連携費用の4区分で条件をそろえて比べ、効果は自社の件数と時間で試算する

Close-up view of hands holding a document over a keyboard in an office.
▽ 写真の出典元

注文の転記と確認に追われる状態は、Web受発注で何が変わり、何が変わらないか

FAXで届いた注文書を見ながら販売管理の画面へ打ち込み、品番や数量があいまいな注文は電話で確かめ、締め時間を過ぎた注文の扱いに毎日迷う。
Web受発注システムの導入で減らせるのは、こうした注文の受け渡し・転記・確認の手間です。
一方で、価格の決め方や在庫の不足といった課題はWeb化しても残ります。
まず自社の注文の流れ(誰が・何を・どの手段で・どれだけ)を棚卸しします。
そのうえで、導入の形、取引先との併存、運用前の決め事と注文データの保存、費用と効果の見積もりの順に判断すれば、段階的に進められます。

注文の流れの棚卸し(誰が・何を・どの手段で・どれだけ)

Web受発注システムは、注文する側がブラウザの画面から品番や数量を入力し、その内容がデータのまま受け取る側へ届く仕組みです。
FAXや電話では、届いた内容を人が読み取り、販売管理や在庫の仕組みへ打ち直していました。
Web化で減らせるのは、主にこの読み取りと打ち直し、そして内容があいまいなときの確認の往復です。

ただし、減らせる量は会社によって大きく違います。
注文の大半がすでにメールの定型の注文書で届いている会社と、手書きのFAXが毎朝まとまって届く会社とでは、同じシステムを入れても手元に残る効果が別物になります。
そのため、製品を比べる前に、自社の注文がどう流れているかを書き出しておくと、後の判断の土台になります。

棚卸しで書き出しておきたいのは、次のような項目です。

<ul><li>誰が:注文してくる取引先(または注文を送る仕入先)と、社内で受け付けて入力する担当者</li><li>何を:よく出る商品、単位や入数の違い、取引先ごとの価格の有無</li><li>どの手段で:電話・FAX・メール・Excel添付など、手段ごとの件数</li><li>どれだけ:一定期間の注文件数と、締め時間の前後や月末への偏り</li><li>例外:急ぎ、分納、特別価格、品番が書かれていない注文などの頻度と、その処理を誰がしているか</li></ul>

数え方は厳密でなくても構いません。
一定期間の注文を手段ごとに数え、例外になったものに印を付けるだけでも、どこに手間が集まっているかは見えてきます。
たとえば、FAXの注文が一部の取引先に集中しているなら、その取引先から移行を相談する道筋が立ちます。
反対に、例外の注文が多く、毎回電話で事情を聞かないと処理できないのであれば、入力画面を用意するだけでは手間が減りにくいことも分かります。

発注側と受注側で判断が変わる点

同じWeb受発注システムでも、自社が注文を受け取る側か、送る側かで、導入によって動かすものが変わります。

受注側として導入する場合、自社が注文画面を用意し、取引先にそこから注文してもらう形になります。
FAXの読み取りと販売管理への打ち直しが減るのは自社ですが、操作を覚え、社内の発注手順を変えるのは取引先です。
効果を受ける人と負担をする人が別になるため、取引先にとっての使いやすさや、移行を頼む順番が判断の中心になります。

発注側の場合は、仕入先ごとに注文の方法が違うことが悩みの中心になることがあります。
仕入先がWeb受付の画面を用意していればそれを使えますが、仕入先ごとにログイン先や入力の作法が異なると、手間が電話やFAXから複数の画面へ移るだけになりかねません。
自社で発注の仕組みを用意して仕入先に受け取ってもらう方法もありますが、その場合は仕入先に受け取り方を変えてもらうことになります。
どちらの立場でも、自社の手間がどれだけ減るかと、相手にどれだけ変化を求めるかを並べて考える点は共通しています。

Web化で変わらない課題

Web受発注で整うのは注文の受け渡しで、その前後にある判断まではシステムが引き受けてくれません。
価格をどう決めるか、在庫が足りないときにどの注文を優先するか、取引先の与信をどう管理するかといった課題は、Web化した後もそのまま残ります。

むしろ、Web化によって前提の整備が表に出ることがあります。
取引先ごとに違う価格を画面に表示するなら、その価格を事前に登録しておく必要があります。
担当者の頭の中にあった「この取引先にはこの単価」という判断が、登録と更新の作業に置き換わるわけです。
在庫を画面に見せる場合も、元になる在庫の数字が日々正しく更新されていなければ、取引先に誤った情報を見せることになります。

確認の手間もなくなるわけではありません。
品番と数量が選択式で入力されれば読み間違いは起きにくくなりますが、急ぎの相談や新しい商品の問い合わせは引き続き人が受けます。
Web化の効果を見積もるときは、減る作業と残る作業を分けておくと、導入後に「思ったほど楽にならない」と感じる食い違いを防ぎやすくなります。

作業 Web化で変わること 残る課題
注文の受け取り 取引先が画面から入力しデータで届く 画面を使わない取引先の注文受付
転記 FAXや電話の内容を打ち直す作業が減る 既存システムへの取り込みと確認
内容の確認 品番や数量の読み間違いが起きにくくなる 急ぎ・新商品・例外の相談
価格と在庫 登録した価格や在庫を画面で示せる 価格の決め方と在庫の正確さと登録の更新
受注側と発注側で変わる負担の違い(模式図)
受注側と発注側で、手間が減る人と変化を求められる人を分けた図

導入の形の選び方:SaaS・自社開発・併用型を、注文の流れと既存システムで比べる

3つの形態を同じ軸で比べる

棚卸しで注文の流れが見えたら、次はどの形で仕組みを用意するかです。
受発注のサービスを提供する竹田印刷の記事は、導入方式としてSaaS、フルスクラッチ開発、その中間にあたるハイブリッドの3つを挙げています3。
SaaSは提供元がインターネット上で運用するサービスを利用する形、フルスクラッチ開発は自社の要件に合わせて一から作る形、ハイブリッドは既製の仕組みを土台に一部を自社向けに作り込む形と考えると分かりやすいでしょう。

同じ記事は、SaaSは初期投資が最も小さく、フルスクラッチ開発は初期費用に加えて保守費用もかかるとし、予算が限られる場合や社内の技術リソースが乏しい場合にはSaaSを勧めています3。
これは受発注のサービスを提供する一社の見解で、業界共通の基準として示されたものではありません。
それでも、形態ごとに何が負担になるかを考える手がかりにはなります。
次の表は、4つの軸で3つの形態の傾向を編集上の考え方として整理したものです。

判断が分かれやすいのは、例外の注文をどこまで画面で受けたいかです。
棚卸しで例外が少なく、商品と価格を登録すれば注文の大半を受けられそうなら、まずはSaaSで標準の流れに業務を寄せる考え方が取りやすくなります。
一方、取引先ごとの独自の受注条件が取引の要になっていて、それを画面で表現できないと取引先が移ってくれない場合は、作り込みを検討する余地が出てきます。

ただ、作り込んだ部分は自社で保守し続ける対象になります。
担当者が替わったときに仕様を説明できるか、改修を誰に頼むかまで考えておかないと、注文を受ける仕組みそのものが特定の人や会社に依存する状態に戻りかねません。
例外の一部は電話で受け続けると割り切り、画面は標準の注文に絞るという選び方もあります。

既存の販売・在庫・会計との連携をどう確認するか

形態を選ぶうえで、もう一つの分かれ目が既存の仕組みとのつながりです。
Web受発注で注文がデータとして届いても、それを販売管理へ人が打ち直しているなら、FAXの転記が画面からの転記に変わっただけになります。

注文データの渡し方には、受発注システムの画面を見ながら手で入力する、ファイルに書き出して取り込む、システム同士で受け渡す、といった違いが考えられます。
手入力のままなら読み間違いは減っても入力の手間は残ります。
ファイルの取り込みなら打ち直しは減りますが、取り込みの操作とエラーの確認をする人が要ります。
システム同士の受け渡しなら日々の作業はさらに減りますが、つなぐための費用や、どちらかの仕組みを更新したときの影響を考える必要があります。
どの方法が使えるかは、製品と既存システムの組み合わせ次第です。

提供元へ確認するときは、「連携できますか」と聞くより、具体的な項目で聞くほうが答えの食い違いを防げます。

<ul><li>注文データをどの形式で出せるか、既存システムがその形式を取り込めるか</li><li>品番・取引先コード・単位が、既存システムの登録とそのまま対応するか</li><li>取り込みの頻度と、締め時間との関係</li><li>取り込みに失敗した注文をどこで見つけ、誰が直すか</li><li>商品や価格の登録を、どちらの仕組みで管理するか</li></ul>

最後の項目は、後回しにすると運用が始まってから困る点です。
商品や価格を受発注システムと販売管理の両方で登録する運用にすると、片方だけ更新して食い違う危険が生まれます。
どちらを元の登録にし、もう片方へどう反映するかを先に決めておくと、運用開始後に何を確認すればよいかがはっきりします。

比べる軸 SaaS ハイブリッド フルスクラッチ開発
初期負担 小さい傾向 作り込む範囲によって増える 初期費用と保守費用がかかる
カスタマイズ性 提供される機能と設定の範囲内 不足する部分を補える 自社の流れに合わせて作れる
既存システムとの連携 提供元が用意する方式に合わせる 作り込みで補える場合がある 要件に入れて作れるが開発と保守が要る
社内の技術リソース 少なくても運用しやすい 作り込んだ部分の管理が要る 開発後の保守体制が要る
注文データの渡し方による違い(模式図)
手で入力する、ファイルで取り込む、システム同士で受け渡す方法の違いを分けた図

取引先に使ってもらうには:段階的な移行と、紙・電話の注文との併存

取引先の負担を先に見積もる

どの形態を選んでも、取引先が画面から注文してくれなければ、FAXと電話は減りません。
受注側として導入する場合、取引先には、アカウントを受け取ってログインする、画面の操作を覚える、社内で注文を回す手順を変える、といった手間が生じます。
取引先の担当者にとっては、自分の業務を軽くする話ではなく、相手の都合で手順を変える話に見えることもあります。

負担の重さは、取引先がほかにいくつの受発注の画面を使っているかでも変わります。
仕入先ごとに別のシステムへログインしなければならないなら、注文する側の手間は画面の数だけ増えます。
これは、発注側として仕入先の画面を使っている立場でも同じ悩みです。

この問題に関わる動きとして、中小企業庁が開発するデータ連携基盤の構想が2021年に報道されています。
業界やサプライチェーンの系列ごとに異なる電子受発注システムに接続して入力データを自動変換し、取引先ごとのシステムを個別に立ち上げずに受発注を一元管理できるという仕組みです1。
同じ報道では、当時の中小企業の電子受発注システムの導入率を約2割とし、2023年をめどに約5割へ引き上げる目標が紹介されていました1。
いずれも2021年時点の構想と目標を伝えるもので、基盤の現在の稼働状況や、いまの普及の度合いを示すものではありません。
ただ、取引先ごとに画面が違うことが負担になるという点は、当時から課題として捉えられていたことが分かります。

自社で導入を決める段階では、取引先ごとに、現在の注文の手段と件数、画面から注文を入力できる環境があるか、ほかのWeb受発注を使っているかを、営業担当などから聞き取っておくと、移行を頼みやすい相手が見えてきます。

一部の取引先・商品から始める

取引先の負担を見積もったら、すべての取引先を一度に切り替えるのではなく、一部の取引先と一部の商品から始める進め方が考えられます。
最初に声をかける相手としては、FAXの注文が多く自社の転記の負担が大きい取引先、すでに別のWeb受発注に慣れている取引先、取引先のほうからWeb化を求めてきた相手などが候補になります。
商品も、品番と単位が決まっていて例外の少ないものから載せると、画面の分かりにくさと商品登録の不備を切り分けて確かめられます。

この期間は、Webの注文とFAX・電話の注文が並んで届きます。
注意したいのは、同じ注文が両方の経路で届くことです。
取引先が念のためにFAXも送ってくると、二重に登録して二重に出荷するおそれがあります。
試行に参加する取引先とは、Webで送った注文はFAXを送らない、変更や取り消しはどの経路で伝える、といった取り決めを始める前に交わしておくと、受け付ける側が迷わずに済みます。

旧来の手段を残すのは、移行に時間がかかる取引先を置き去りにしないためでもあります。
電話でしか伝えにくい急ぎの相談や例外の注文は、Web化が進んだ後も電話で受けると決めておくほうが、画面に無理に詰め込むより取引先にとって分かりやすい場合があります。

併存期間中に確かめる指標

併存期間を終える時期は、日付だけで決めるより、数字の動きを見て決めるほうが判断の理由を説明しやすくなります。
見ておきたいのは次の3つです。

<ul><li>Web注文の比率:試行の取引先の注文のうち、Webで届いた割合</li><li>問い合わせの件数:操作方法や注文内容についての電話・メールの数</li><li>例外注文の件数:画面で受けられず、人が個別に処理した注文の数</li></ul>

Web注文の比率が伸びないときは、画面が使いにくいのか、取引先の社内手順が変わっていないのか、FAXのほうが早いと感じられているのかを、問い合わせの中身から探ります。
問い合わせが減らない場合は、商品名や単位の表示が取引先の呼び方と合っていないことがあります。
例外の注文が多いまま減らないなら、その種類の注文は画面に載せずに電話で受けると決めることも選択肢です。

これらの数字が落ち着いてきたら、FAXの受付を縮小する時期を取引先に早めに伝えます。
段階的に進めれば必ず移行がうまくいくわけではありませんが、数字を見ながら進めれば、どこでつまずいているかを取引先と同じ材料で話し合えます。

取引先への段階的な移行の進め方
聞き取り、一部の取引先と商品での開始、数字を見ての追加、FAX受付の縮小告知という移行の流れ

運用開始前に決めておく項目と、電子取引データの保存

商品・価格・締め時間・例外注文の決め方

試行を始める前に、画面に載せる情報と、注文を受けた後の扱いを決めておく必要があります。
FAXや電話のやり取りでは担当者がその場で補っていた判断を、取引先が画面だけで注文できるように、先に言葉と設定にしておく作業です。

<ul><li>商品:品番、名称、単位(個・箱・ケースなど)、入数、取引先から見て分かる呼び方</li><li>価格:全取引先共通か、取引先ごとか、画面に表示するか</li><li>締め時間:何時までの注文を当日扱いにするか、締め後の注文をどう扱い、画面でどう伝えるか</li><li>変更と取り消し:取引先が自分で直せる範囲と期限、それを過ぎたときの連絡先</li><li>例外注文:急ぎ、分納、画面にない商品を、どの経路で誰が受けるか</li><li>受付の連絡:注文を受け付けたことを取引先へどう知らせるか</li><li>社内の権限:誰が商品や価格を登録・変更でき、誰が注文を処理するか</li></ul>

中でも単位と締め時間は、食い違うと取引先との行き違いに直結します。
FAXでは数量だけが書かれていても、担当者が過去の注文から箱単位だと判断できました。
画面では、選ばれた単位がそのまま注文になります。
締め時間も、画面に表示していなければ、取引先は締め後に送った注文が当日扱いになると思い込むかもしれません。
ここを曖昧なまま始めると、問い合わせの件数として跳ね返ってきます。

注文データの保存方法を提供元に確認する

運用前に決めておくことのうち、法令にかかわるのが注文データの保存です。
電子帳簿保存法は、帳簿や取引の書類を電子データで保存するときのルールを定めた法律です。
国税庁の一問一答は、注文書や見積書などに相当する取引情報を電子的にやり取りした場合を電子取引とし、その電子データを保存する義務があるとしています2。
Web受発注で受け渡す注文のデータも、この電子取引に当たりうると考えて準備しておくのが安全です。

保存の方法について、同じ一問一答は、提供事業者のシステムにデータが保存される受発注サービスでは、その保存機能を使う方法と、データを自社のシステムへ取り込んで保存する方法があることを示しています2。
どちらが取れるかは、サービスごとに保存の仕組みが違うため、選ぶ段階で提供元に確かめておくことになります。
確かめるときは、次のような点を具体的に聞いておくと、比較の材料になります。

<ul><li>注文データがサービスの中にどのくらいの期間残るか</li><li>解約や乗り換えのときに、過去の注文データを取り出せるか、その形式は何か</li><li>取引の日付・金額・取引先で過去の注文を探せるか</li><li>自社のシステムへ取り込む場合、どの項目が取り込まれるか</li></ul>

発注側として仕入先の画面から注文している場合も、注文の情報を電子的にやり取りしている点は同じです。
注文データが仕入先のシステムにしか残っていないと、仕入先の画面の仕様が変わったときに、自社で過去の注文を見られなくなるおそれがあります。
自社の側でどう保存するかも、受注側と同じように決めておく対象になります。

なお、一問一答では、2024年以降、基準期間の売上高が一定額以下の事業者などについて、検索機能の確保を求められない措置も扱われています2。
対象は所得税・法人税の保存義務者で、この措置に当たるかどうかや、選んだ保存方法で足りるかは、事業者ごとの状況で変わります。
条件は最新の国税庁の資料で確かめ、税務上の判断は税理士などに相談してください。

注文データの保存方法ごとに確かめる点(模式図)
サービス内に保存する方法と自社のシステムへ取り込む方法で、提供元に確認する点を分けた図

費用の構成と、自社の効果をどう見積もるか

見積もりを4区分で比べる

費用に見合うかを判断するには、まず複数の見積もりを同じ物差しで並べる必要があります。
提供元によって料金の示し方が違うため、次の4区分に分けて書き写すと比べやすくなります。

<ul><li>初期費用:設定、商品や取引先の登録の支援、操作説明など、始めるときに一度かかる費用</li><li>月額:利用料と、それがアカウント数・取引先数・注文件数などで変わるかどうか</li><li>オプション:標準にない機能を追加するときの費用</li><li>連携費用:既存の販売・在庫・会計の仕組みとつなぐための費用</li></ul>

竹田印刷の記事は、SaaSは初期投資が小さい一方、オプション機能やカスタマイズで追加の費用が出ることがあると述べています3。
同社は具体的な目安額も挙げていますが、どの製品やプラン、どの規模を前提にした額かは特定できないため、自社の相場として当てはめるより、見積もりのどこに追加費用が出やすいかを読む手がかりとして使うのが妥当です。
月額が安く見えても、必要な連携やオプションを足すと、比べた順位が入れ替わることがあります。

見積もりを依頼するときにそろえておきたい条件は、取引先の数、商品の点数、月あたりの注文件数の見込み、既存システムとの連携方法、注文データの保存期間と取り出し方、操作説明やサポートの範囲、契約期間です。
この条件が提供元ごとにばらばらだと、安く見えた見積もりが、単に範囲の狭い見積もりだったということが起こります。
棚卸しで書き出した件数と、運用前に決めた項目は、そのままこの依頼の条件に使えます。

見積もりに載らない社内の作業もあります。
商品や価格の登録、取引先への説明、試行期間の問い合わせ対応は、提供元の支援がある場合でも自社の人手がかかります。
導入直後はFAXとWebの両方を受けるため、一時的に作業が増えることも計算に入れておきます。

自社の件数と所要時間で試算する

効果のほうは、他社の削減例を借りるより、自社の数字で試算したほうが社内で説明しやすくなります。
使うのは、棚卸しで数えた手段ごとの注文件数、注文ごとの転記と確認にかかっている時間、誤りの件数とその訂正にかかる手間です。

考え方は単純です。
Webへ移せそうな注文の件数に、注文ごとの転記と確認の時間をかけると、減らせる見込みの作業時間が出ます。
そこから、取り込みの確認や例外の対応など、Web化後も残る作業の時間を差し引きます。
誤りについても、訂正の電話や再出荷にかかっていた手間のうち、品番や数量の読み違いによるものを分けておくと、Web化で減る部分が見えます。

この見込みを、見積もりの月額や、初期費用を利用を想定する期間で割った額と並べると、費用に見合うかを考える材料になります。
試算はあくまで見込みで、試行の取引先でWeb注文の比率がどこまで上がるかによって変わります。
最初の試算は幅をもたせ、試行の結果で見直す前提にしておくと、社内での説明も実態から離れにくくなります。

時間に換算しにくい効果も書き添えておきます。
締め時間後の注文を翌朝まとめて確かめる負担や、特定の担当者が休むと注文の処理が止まる状態は、件数と時間だけでは表せません。
こうした点が導入を考え始めたきっかけなら、数字の試算と並べて、何が解消されれば成功とするかを言葉で決めておくと、判断がぶれにくくなります。

見積もりを比べる4つの費用区分(模式図)
初期費用、月額、オプション、連携費用の内容を分けた図

検討からWeb受発注システム導入までの手順と期間の組み立て方

並行できる作業と順序が要る作業

ここまでの判断を、実際の進め方に並べ直します。
順番に決めていく必要があるのは、棚卸し、導入の形と候補の絞り込み、見積もりと保存方法の確認、試行、本格的な移行です。
前の判断の結果が次の判断の条件になるため、たとえば棚卸しの前に製品を決めると、例外注文の多さや連携の必要に合わない選択をしてしまうことがあります。

一方で、決定を待たずに進められる作業もあります。

<ul><li>商品と取引先の登録情報の整理(品番、単位、取引先ごとの価格)</li><li>締め時間・変更・例外注文など運用ルールの案づくり</li><li>試行に誘う取引先への事前の聞き取りと説明</li><li>社内の担当と、問い合わせを受ける窓口の決定</li></ul>

中でも商品と取引先の登録情報の整理は、どの製品を選んでも必要になり、量によっては時間がかかります。
品番の表記ゆれや、もう使われていない商品の登録が残っていると、そのまま画面に載ってしまいます。
検討の早い段階から手を付けておくと、製品が決まった後の待ち時間を減らせます。

判断の区切りと確かめる指標

期間は、取引先の数、商品の点数、連携の有無によって大きく変わるため、一律の日数で見積もるのは難しいところです。
代わりに判断の区切りを置き、その区切りごとに何が分かっていれば次へ進むかを決めておくと、計画が遅れたときにも理由が見えます。

最初の区切りで導入を見送るのは、失敗ではありません。
例外の注文が大半を占める、取引先の多くが画面での注文を望んでいない、といった状況が棚卸しで分かったなら、メールで届く注文書の形式をそろえるなど、Web化の手前でできる改善から始めるほうが合う場合もあります。

試行の後の区切りでは、数字が思わしくなくても、すぐに導入をやめるか続けるかの二択にする必要はありません。
取引先を絞る、画面に載せる商品を減らす、例外は電話で受けると決めるといった範囲の調整で、続けられることもあります。

上長への説明でも、この区切りは使えます。
「いつまでに導入するか」だけでなく、「どの数字が確認できたら次へ進むか」を示しておけば、試行の結果が思わしくないときにも、計画を止めるのか、範囲を絞るのかを同じ材料で話し合えます。

導入までの判断の区切りと確かめる条件
棚卸し後、見積もりと保存確認の後、試行の後、本格移行の前の4つの区切りと、それぞれで確かめる条件

棚卸しや試算は自社で進められますが、例外の注文をどこまで画面に載せるか、既存の仕組みとどうつなぐかは、受発注の業務と仕組みの両方を見ないと判断が分かれます。

書き出した注文の流れをもとに、Web化する範囲と電話・FAXで残す範囲、提供元へ確認したい項目を整理できます。無料相談で要件を整理する

要点の整理

軸 基準
Web化の対象 転記と確認の手間が集まっている注文の手段と取引先
導入の形 例外注文の多さ、既存システムとの連携、社内の技術リソース
取引先との併存 一部の取引先と商品から始め、Web注文の比率・問い合わせ・例外注文の件数で判断
運用前の決め事 商品の単位、価格、締め時間、変更と取り消し、例外注文の窓口
注文データの保存 保存場所・期間・取り出し・探し方を提供元に確認し、適用は国税庁資料と税理士などで確認
費用と効果 4区分で条件をそろえた見積もりと、自社の件数と時間による試算

見積もりの条件が提供元ごとにそろっていないと、費用と効果を同じ物差しで比べられません。 手元の見積もりと試算を持ち込めば、そろっていない条件や確認が漏れている項目を洗い出せます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

発注側と受注側では、導入の判断はどう変わりますか。

受注側は自社が注文画面を用意し、取引先に入力してもらう形になるため、取引先の負担と移行を頼む順番が判断の中心になります。
発注側は仕入先ごとに注文方法が違うことが課題になりやすく、仕入先の画面を使うのか、自社の仕組みから送るのかで、相手に求める変化が変わります。
どちらでも、自社の手間がどれだけ減るかと、相手にどれだけ変化を求めるかを並べて考えます。

取引先がWeb注文に対応できない場合、電話やFAXの注文はいつまで残しますか。

日付で一律に決めるより、試行した取引先のWeb注文の比率、問い合わせの件数、例外注文の件数が落ち着いたことを確かめてから、縮小の時期を早めに伝える進め方が考えられます。
急ぎの相談や例外の注文は、移行後も電話で受けると決めておく選択肢もあります。

Web受発注で受け取った注文のデータは、電子帳簿保存法の保存対象になりますか。

国税庁の一問一答では、注文書などに相当する取引情報を電子的にやり取りした場合は電子取引とされ、その電子データを保存する義務があるとされています2。
Web受発注の注文データも当たりうるため、サービス内に保存するか自社へ取り込むかを提供元に確認しておきます。
対象は所得税・法人税の保存義務者で、個別の適用は最新の国税庁の資料と税理士などで確かめてください。

SaaSと自社開発の違いは、何を基準に選べばよいですか。

初期負担、カスタマイズ性、既存システムとの連携、社内の技術リソースの4つの軸で比べます。
ある提供事業者は、予算が限られる場合や社内の技術リソースが乏しい場合にSaaSを勧めています3。
例外の注文が少なく標準の流れに寄せられるならSaaSを検討しやすく、独自の受注条件が取引の要になっている場合は作り込みを検討しますが、作り込んだ部分を保守し続ける体制も必要になります。

既存の販売・在庫・会計システムとつながるかは、導入前に何を確認しますか。

注文データを出せる形式と既存システムが取り込める形式、品番・取引先コード・単位の対応、取り込みの頻度と締め時間の関係、取り込みに失敗した注文の見つけ方と直す担当、商品や価格をどちらの仕組みで管理するかを確認します。
「連携できるか」だけを聞くと、手で入力する前提なのか、ファイルで取り込むのかといった違いが見えにくくなります。

費用の見積もりを複数集めるとき、どの条件をそろえて比べますか。

取引先の数、商品の点数、月あたりの注文件数の見込み、既存システムとの連携方法、注文データの保存期間と取り出し方、操作説明やサポートの範囲、契約期間をそろえて依頼します。
受け取った見積もりは、初期費用・月額・オプション・連携費用の4区分に分けて並べると、範囲の違いが見えやすくなります。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:日刊工業新聞社(ニュースイッチ)「中小企業庁が中小企業の電子受発注実現へ開発する「データ連携基盤」の全容」(2021年)
  2. 2 出典:国税庁「電子帳簿保存法一問一答【電子取引関係】令和6年6月」(2024年)
  3. 3 出典:株式会社竹田印刷(TS-BASE運営)「Webの受発注システムの選び方とコストの目安」(2026年)

画像の出典元

  1. Close-up view of hands holding a document over a keyboard in an office./Photo by Kampus Production on Pexels

Photos provided by Pexels

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top