業種・業界や取引形態や関わるコストや利益構造などおそらく基準はそれぞれかと
思います。
流通に身を置く立場として、私個人の意見を書かせて頂きます。
なぜ受注システムを導入するのか？
検討する・導入する為の根幹は、もっておいた方がいいかと思います。
ただ単なるDX化の一環で「根幹」が無いと全く意味のないものとなります。
一言で言えば、「生産性アップ」の為です。
人不足・賃金上昇の外部環境を考えると、一人当たりの生産性をアップさせる事は非常に重要です。
BtoB受発注をオンライン化するメリット
受注処理を一元化でき、属人性を排除できる
FAXやメールなど受注処理の対応がバラバラだったものが、システムに一元化される事で、受注システムの処理だけを覚えればよくなる。
また、処理が一つになる事で、人員配置や休暇時対応も楽になる。
データによる発注の為、過去が楽
受注データを基幹システムに流し込むことも可能となり、手打ちの手間削減・事務ミス削減につながる。
問い合わせの削減
サイトを通じて、様々な情報伝達や出荷の連絡を行えるので、取引先からの問い合わせが減少する事で対応手間が削減できる。
決済や納品書などの副次的効果
企業間決済やカード決済を使用できるようになれば、取引の幅も増えるかもしれません。
納品書の郵送も無くなるかもしれません。
導入後、様々な副次的な効果に気付いてくると思います。
BtoB受発注WEBシステム
卸サイト・BtoBサイト・受発注システム・WEB受発注など言い方はいろいろあるとは思いますが、以降は、「受注システム」と言わせて頂きます。
- ECカートを利用している受注システム（カート型）
- データのやり取りを主軸としている受注システム（データのやり取り型）
ECカートを利用している受注システム（カート型）
商品登録数で価格が決まっていることが多いです。
BtoC事業でネット販売を行っている場合、とっつきやすい。
（仕組みとしては、楽天・ヤフーのシステムと登録や処理方法がほぼ同じなので。
商品登録が必要。
登録されている商品のみ発注できる。
分納や一部出荷が出来ない（制限がある）
・メイクショップ
・Bcart（ビーカート）
などなど
データのやり取りを主軸としている受注システム（データ交換型）
行数や伝票数で価格が決まっていることが多いです。
（カート型と比べてコストが高額。）
システムによってはファイルのやり取りしか出来ない事もある。
分納や一部商品出荷が出来ない場合がある。
商品登録は不要の場合が多い。
イメージしにくかもですが、ちなみに以下はバクレックス
発注データをダウンロードして、基幹システムに取り込んで、そんでもって、出荷データを送信するという感じです。
ハイブリッド型（カート型とデータ交換型のハイブリッド）
カート型並みの価格とデータ交換型のいい部分を合わせたハイブリッド型のため、中小企業でも使用しやすい。
社内の体制と取引先内容などによりどちらがいいか変わってきます。
価格的におどちらが安いかは、取引内容によりますし、後述する機能によっても大幅に
変わってくると思われますので、一概にどちら！とは言えません。
なので、失敗も重ねた私の考える確認事項についてお話していきます。
確認しよう。
商品SKU（商品数）は？
カート型は、殆どが商品点数で価格が決まっています。
費用面も重要かもしれませんが、カート型の問題点は、むしろページ作成の手間と思います。
商品が、少なく、改廃も殆ど無いという場合は、楽なのですが、商品点数が多く、
毎年改廃がある。といったジャンルの場合、商品ページのメンテが必要になります。
きれいにするために商品の説明をしていくとなると、一つ一つのメンテが必要となってきます。
また、CMS（＊１）での作成ではありますが、トップページやカテゴリページなど見た目をきれいにする為に、
バナー作成やページを整える必要があります。
＊CMS・・・HTMLやCSSの知識が無くても簡易にホームページが作れるシステム
カート型の場合は、受注サイト管理担当は必要！
一方、データのやり取り型の場合は、商品ページというものは存在しないのでメンテ不要です。
業務システムと同じで、商品マスタを使用しているシステムもありますが、コードや価格などの
データのみで有る為、既存社員でも対応は簡単です。
商品マスタを使用しないシステムにおいては、”発注””出荷”というデータの受け渡し
のみなので、極論を言えば、契約初日から受注が受けられます。
あくまでデータのやり取りに特化しているので、カート型のようにサイトにて”ついで買い”を
誘発するなど、購入する商品が決まっていない取引先に対してのアピールは弱くなります。
分納や一部出荷（注文残高について）
業界により違うとは思いますが、”分納”や”一部出荷”の対応が出来るか？
受注システムを選ぶ際に、この部分を気にせず選んで失敗している会社さん、よくあります。
（わが社もそうでした・・・）
注文された数量に対し、複数回に分けて出荷する事。
単純に在庫が無かったや、先方との交渉でそうなったなど、理由は様々です。
例えば、100個の注文に対し、6/1に30個出荷、7/1に70個出荷する。みたいな感じです。
”分納”が処理出来ないとどうなるか？
6/1に100個の注文を30個に修正して出荷処理します。
残り70個は、システム上はキャンセル扱いするか、未出荷の状態で宙に浮かせておくかなど、きちんと残しておくことはできません。
また、カード決済の場合で一旦キャンセル扱いの場合、カードのキャンセル処理を行う必要があります。
いわゆる「注文残高」を残す事が出来ません。
（私の所感では、出来ないシステムが殆ど。）
”一部出荷”とは、複数点の商品の注文に対し、一部の商品のみ出荷する事です。
在庫が無かったや未発売など理由は様々です。
例えば、商品Aを10個、商品Bを5個の注文に対し、6/1に商品Aだけを出荷する。みたいな感じです。
（BtoBの場合、結構有ると思うのですが・・・）
”一部出荷”が処理できないとどうなるか？
方法１
商品Aを出荷する際に、商品Bは、0個に訂正（キャンセル）を行い出荷する。
方法２
商品Bが出荷できるまで、商品Aを出荷しない。
要は、注文単位で”注文残高”を残す事ができない。
こちらも、この仕組みのシステムがかなり多い！
”分納”、”一部出荷”ともに”注文残高”という概念があるかどうかなのですが、
どちらかというと、”データのやり取り型”の方が、”注文残高”を意識している作りになっているような
感じがします。
”注文残高（注残）”が発生する業界なら、必ず確認すべき！
取引先毎の単価が設定できるか？
商品の価格が、取引先やグループによって、違う単価を設定できるか？という事です。
取引先によって、卸価格が違うというのは、どの業界でもあるのではないでしょうか？
”データのやり取り型”で、注文数量だけ把握できればいい。という会社はあまり気にする必要はありません。
（基幹システムの単価を出荷時に入れる為です。）
主には、”カート型”の場合で、”卸サイト”を標榜しながら、グループ単価・取引先単価を設定できないシステムもありますので、注意です。
ただ、実務的には、結構考えないといけない事があります。
受注システムへの個別単価を入れるという事は、会社の基幹システム内とは別に単価マスタが出来る事となります。
基幹システムのマスタと受注システムのマスタ マスタのダブルメンテが必要になってきます。
決済方法について
受注システムで決済ができるのかどうか？
請求書での締め取引にて、既存の取引先との取引がメインの場合は、あまり関係ないかもしれません。
新規取引先や締め取引ができない取引先への決済方法として有効なのが、企業間決済・カード決済です。
また、注文残高が出てくる場合は、”企業間決済”の方が優先事項かもしれません。
データの出し入れ
1日数件の発注であれば、手動処理でなんとかできるかもしれません。
ただ、1日数十件以上の注文となると、手動処理も大変だと思います。
その為に事前に自分の会社において、検討受注システムが使えるのか？を確認する必要があります。
（ある程度はマニュアルなどで確認できますが、実際は、デモでテスト運用しないと分からない点も多々。）
ここが検討にて、一番時間かかるかもしれません。
・受注システムより受注データをダウンロードして、基幹システムに取り込めるか？
・基幹システムから出荷データを受信システムへアップロードできるか？
（カート型の場合は、送り状番号を受注システムへアップロードできるか？）
発注側からの景色
正直言って、発注側からすると「カート型」の受発注システムは面倒くさいです。
発注側から見える”カート型”のサイトは、通常のネットショッピングのページです。
一つ一つ検索して、その商品ページまで行ってカートに入れて、発注しないといけないんだ。
そもそも注文する商品決まっているのにめんどくさ～い
BtoBの場合、発注する商品が決まっている為、カートに入れるという操作自体が非常に面倒です。
１つや２つならいいですが、10商品注文するのにめちゃくちゃ時間かかります。
（CSVで発注をアップロードできる”カート型”のシステムも少しはあります。）
以上の点から、”カート型”の受注システムは、発注者が受け入れてくれない問題に
直面する場合があります。
件数が多い優良取引先程、面倒なので、受け入れてくれず、でも件数が多い取引先が
受け入れてくれないと、受注システムを導入した意味がない可能性があります。
（わが社でもその観点で失敗した事あります。。。）
まとめ
受注システムの検討って、非常に難しくて、がっつり実務やっている人が検討するのと、管理の人が
検討するので、見る景色が変わってきます。
なんとなく、”IT”を使った受注システム使えば、生産性上がるんだろ！みたいな感じで選ぶと
全然効果がありません。
（トップダウンだと絶対うまくいきません！逆に効率が悪くなる可能性もあります。）
なので、検討する際は、必ず実務の方と一緒に検討されることをお勧めします。
検討する際は、必ず実務の方と一緒に検討する事！
確認事項のまとめ
- 商品ページやサイトに人を割けるのか？
- 注文残高に対応しているか？
- 取引先毎の単価を設定するのか？
- 決済方法を増やすのか？
- 数十件以上の受注処理をイメージできているか？
- 力関係も含め、取引先は受け入れてくれそうか？
個人的感想
自分の会社の状態によるかと思います。
相手に対して強く言える立場の会社の場合は、”データ交換型”。
中小企業の場合は、”ハイブリッド型”。
小さい取引先が多く、注文される商品種類も少ないのであれば、”カート型”。
わが社は、ハイブリッド型の「マルゴート」を使用しています。
コメント