スマホ発注は多拠点の倉庫・店舗にどう導入する？拠点管理の実装例と確認すべき4つの軸

◆監修・編集責任者　小園 将隆　2026年9月25日

B2B EC-COLUMN

拠点をまたぐ発注、FAX・紙のままだと何が起きているか

A倉庫は仕入先へFAX、B店舗は電話、C店舗は担当者の手帳。
本部が拠点ごとの発注量をまとめて見られるのは締めのあと——拠点が増えるほど、やり方の違いがそのまま残ります。
公開されている製品情報で確認できる範囲では、スマホ発注は商品のバーコードを読んで数量を入れる操作に変わり、拠点ごとにアカウントを分けて管理する実装例もあります。
一方で、権限管理・承認フロー・オフライン対応・既存システムとの連携は製品ごとに作りが異なり、標準仕様と呼べる記載までは確認できませんでした。
多拠点で選ぶときは、この4点を各社へ個別に確認したうえで、自社の拠点数と仕入先の構成から確認の優先順位を決める進め方になります。

文字判読・入力ミスが起こる理由

紙とFAXで発注が回っているとき、負担が出るのは注文書を書く時間そのものよりも、書いた内容が相手にどう届くかの部分です。
手書きの品番や数量は、送信の過程で線がつぶれたり、6と8、1と7の見分けがつきにくい字になったりします。
受け取った側は、その紙を見ながら自社の受注システムへ打ち直すことになります。

導入事例として公開されている記録では、受注側でFAX受注について文字判読の困難さ、解析にかかる時間の長さ、入力ミスの頻発が挙げられています⁴。
これは卸（受注側）の事例で、発注する店舗や倉庫の側の作業時間を示した数値ではありません。
ただ、打ち直しのどこかで数量が1桁ずれれば、その結果は納品された箱の数という形で発注側にも返ってきます。

発注側で「なぜ頼んだものと違うものが届いたのか」をたどると、手元のFAX控えと納品書を突き合わせる作業になります。
拠点が1つなら控えの束を探すだけで済みますが、拠点が複数あると、どの拠点がどの便で送った分なのかを特定するところから始まります。
発注そのものは数分でも、食い違いを追う時間は拠点の数に応じて増えていきます。

処理時間と属人化の関係

同じ事例では、FAX受注の処理に1アイテムでも数分、複数アイテムが並ぶと1時間程度かかっていたと記されています⁴。
繰り返しになりますが、これは受け取る側にかかっていた時間です。
発注する側から見ると、この時間は「送ってから注文が確定するまでの待ち」として現れます。
締め切りの直前にFAXを流した分は、確定が翌日にずれる余地が残ります。

もう一つ、紙の発注には書き方の暗黙のルールがついて回ります。
A倉庫では備考欄に「いつもの銘柄」と書けば通じる、B店舗は箱数で書く、C店舗はバラ数で書く。
そのルールは注文書の様式ではなく、書いている担当者の頭の中にあります。
担当者が休んだ日に代わりの人が書くと、単位の取り違えや仕入先ごとの慣習の抜けが起きやすくなります。

本部の側から見ると、困るのは「いま各拠点が何をどれだけ頼んでいるか」が手元にないことです。
各拠点が仕入先へ直接FAXを送っている限り、本部に集まるのは請求書か納品書、つまり事後の紙になります。
発注のやり方をスマホに寄せたいという相談の多くは、入力を楽にしたいという話と、この事後にしか見えない状態を変えたいという話が重なっています。

スマホ発注で現場の操作はどう変わるか

棚の前で発注が終わるまでの操作

では、スマホ発注に切り替えると現場は何をすることになるのか。
公開されている製品情報で確認できる操作の一例として、Pittaly Orderでは発注したい商品のバーコードをスマートフォンのカメラでスキャンし、数量を入力するだけで発注できるとされています³。
専用の端末を持ち歩く必要がなく、手元のスマートフォンのカメラを使う形です。

この操作が現場にとって何を変えるかというと、書いて運ぶ工程が減る点です。
紙の運用では、棚の前でメモを取り、事務所へ戻って注文書に清書し、FAXで送るという三つの動きがありました。
スキャンと数量入力が棚の前で完結すれば、メモから注文書への写し替えがなくなります。
写し替えが1回減れば、そこで起きていた品番の読み違いも減ります。

ただし、この操作はバーコードで管理された定型商品を扱う場面の例です³。
バーコードが振られていない資材、その都度サイズや仕様を指定する商品、仕入先の独自品番でしか通らない商品は、同じ手順にならないことがあります。
自社の発注品目のうち、どれだけがスキャンで拾えるかは、製品を比べる前に自分で数えておける情報です。

送ったあとに何を見られるか

発注は送って終わりではなく、「あれ頼んだ？」に答えられるかまでが業務です。
Pittaly Orderでは、スマートフォンとWebの両方でいつでも発注履歴を確認できるとされています³。
棚の前ではスマートフォンで、事務所ではパソコンの画面で、同じ履歴を見る形です。

紙の運用では、この確認がFAX控えの束をめくる作業でした。
控えが事務所にあれば、倉庫にいる人は電話で聞くしかありません。
履歴が端末から見られると、聞かれた側が手を止めて探す時間がなくなります。

気をつけたいのは、自分が送った履歴を見られることと、本部が全拠点の発注状況を一覧できることは別だという点です。
どこまで見えるかは、アカウントをどう分けて登録するかで決まります。
そこが、多拠点で使うときに最初に詰めておく設定です。

複数拠点・複数担当者をどう分けて管理するか

拠点ごとにアカウントを分ける方法

拠点をどう分けるかについては、実装例を公式ページで確認できます。
CO-NECTの発注側の説明では、店舗ごとに発注情報の管理を分けたい場合は事業者を複数登録して使い分ける運用とされ、登録数の制限や追加料金はないと記載されています²。
拠点を一つの単位として登録し、そこに発注先や履歴をひも付けていく形です。

分けるか、まとめるかで見え方が変わります。
拠点ごとに事業者を分ければ、履歴や発注先が拠点単位でまとまり、A倉庫の担当者が開いたときにB店舗の注文が混ざりません。
逆に一つにまとめれば、同じ仕入先への注文を一か所で見られますが、どの拠点の分かは注文の中身で判断することになります。
拠点ごとに仕入先や単価が違うなら分ける理由が立ちますし、全拠点が同じ仕入先から同じ商品を引いているなら、まとめたほうが管理は軽くなります。

これはCO-NECTの発注側アカウントに関する記載に基づく一例で、他の製品が同じ作りとは限りません²。
製品によって、拠点を分ける単位が契約なのか、契約内の区分なのかは異なり得ます。
「拠点ごとに分けられますか」という質問だけだと、どの製品もはいと答える余地があるため、分けたときに履歴・発注先・利用者がそれぞれどう分かれるのかまで踏み込んで確認するのが実務的です。

複数担当者での共有閲覧

拠点を分けたうえで、その拠点を誰が使うかという話になります。
同じ発注側の説明では、複数のユーザーを登録すれば、それぞれの端末で同じ情報を閲覧・操作できるとされています²。
一人の担当者の端末に情報が閉じない、という意味です。

発注担当を固定できない現場では、ここが効きます。
早番が棚を見て発注し、遅番が続きを確認する、社員が休んだ日にパートの方が代わりに送る、といった動き方をしたとき、前の人が何を送ったかが画面に残っています。
引き継ぎのメモや、口頭での申し送りに頼る部分がそのぶん減ります。

一方で、全員が同じ情報を操作できる状態は、裏返せば誰でも発注を確定できる状態でもあります。
数量を打ち間違えたまま送信された注文が、誰の操作だったのか、送る前に誰かが見ていたのか。
ここを制御するのが権限管理と承認フローで、多拠点になるほど重みが増す部分です。

導入前に個別確認が必要な4つの軸（権限管理・承認フロー・オフライン対応・既存システム連携）

権限管理・承認フローは製品ごとに異なる

権限管理と承認フローについては、公開されている製品情報の範囲では、これが標準の作りだと言える記載までは確認できませんでした。
つまり、どの製品でも同じようにできると考えて比較を進めると、契約後に運用が合わないことが起こり得ます。
製品ごとに違うものとして、個別に確認する項目だと捉えるのが安全です。

確認するときは、機能名から聞くより先に、自社の役割分担を文章にしておくと話が早く進みます。
「拠点の担当者は発注を作れるが、確定は店長」「1回の発注が一定額を超えたら本部の承認を挟む」「新しい仕入先の追加は本部だけができる」——こうした実際の運用文を示して、そのとおりに設定できるかを聞く形です。
役割を分けられるかどうかだけでなく、分けた結果が履歴に残るか、誰が確定したかを後から追えるかまで含めて確認しておきます。

承認を挟むと、現場は待つことになります。
棚の前で発注を作っても、承認者が見るまで仕入先には届きません。
仕入先の締め時間が夕方にあるなら、承認が翌朝になった分は1日遅れます。
承認を入れるかどうかは、誤発注を防ぐ効果と、確定までの時間が延びる負担の兼ね合いで決める話で、全拠点に一律で入れる必要があるとは限りません。

オフライン対応の有無は個別確認が必要

倉庫の奥、冷蔵・冷凍庫の中、地下の資材置き場、鉄骨や金属棚に囲まれた通路。
電波が届きにくい場所は多くの現場にあります。
棚の前で入力できることがスマホ発注の利点である以上、その場所で通信が切れたときにどうなるかは、使えるかどうかを左右します。

この点についても、公開されている製品情報の範囲では、対応の有無を確定できる記載は確認できませんでした。
そのため、電波が悪い場所でも使えるという前提を置かずに確認する必要があります。
聞き方は、対応の有無を一言で尋ねるより、動きを具体的にするほうが食い違いません。
圏外で商品をスキャンして数量を入力したとき、その入力は消えるのか、下書きとして端末に残るのか。
圏内に戻ったら手動で送るのか、自動で送られるのか。
送信が済んだかどうかを画面で区別できるのか。

可能なら、試用の段階で一番電波の悪い場所を実際に歩いて試します。
カタログ上の対応可否より、自社の建物での実測のほうが判断材料になります。
もし対応していない場合でも、電波の届く通路までメモを持って移動する運用に落とせるなら、致命的にはなりません。
逆に、冷凍庫の中で棚卸しながら発注する想定なら、ここは優先して詰める軸になります。

既存の受発注・在庫管理システムとの連携方法も要確認

すでにパソコンで在庫管理システムや受発注システムを使っている場合、スマホ発注を足すと、発注の情報が二か所に生まれます。
スマホで送った注文を、あとから在庫システムにも入力しているようでは、紙の打ち直しが画面の打ち直しに変わっただけです。
連携の確認は、この打ち直しが本当に消えるかを見る作業になります。

どんな連携方式が用意されているかは製品ごとに異なり、一般的な選択肢として断定できる情報は確認できていません。
そこで、方式の名前から聞くのではなく、いま人が手で入力している画面を具体的に挙げて確認するほうが確実です。
「発注を確定したあと、この在庫システムの発注登録画面への入力はなくなりますか」「なくならない場合、どの形でデータを渡せますか」「渡したデータは誰が、どのタイミングで取り込みますか」という順で聞くと、作業が残るかどうかが見えます。

あわせて、品番の対応づけを誰が整えるかも確認しておきます。
スマホ発注側で使う商品コードと、既存システムの品番が同じとは限らず、違えば対応表を作る手間が最初に発生します。
また、発注のデータが連携できても、入荷時の検収や入庫数の入力は別の作業として残る場合があります。
連携によって何の転記がなくなり、何が残るのかを、導入前に線を引いておくと、稼働後に「思っていたのと違う」が起きにくくなります。

現場の年齢層に関わらずスマホ発注は使えるか

スマートフォンの利用率から見えること

多拠点の現場でよく出るのが、「うちのパートさんは年齢層が高いので、スマホの操作は無理ではないか」という懸念です。
まず利用の状況を見ると、個人のスマートフォンによるインターネット利用率は2024年に74.4%となっています¹。
年齢別では、60歳で78.8%、70歳で53.0%です¹。
60代でも7割を超え、70歳でも半数はスマートフォンからインターネットを使っている計算になります。

ただし、これは個人がスマートフォンでインターネットを使っているかどうかの統計であり、発注アプリの操作に慣れているか、導入後に定着するかを示す数値ではありません¹。
日常的に画面をタッチして文字を読む動作に抵抗がない人が一定割合いる、という前提の話までです。
そこから先の使いこなしは、覚える操作の数と、現場の条件で決まります。

覚える操作の数と端末の条件で考える

覚える操作の数という見方をすると、バーコードをスキャンして数量を入力するという流れ³は、手順そのものは多くありません。
一方で、ログイン、拠点の切り替え、承認待ちの確認といった動きが加わると、覚えることは増えます。
年齢よりも、日常的に行う操作が何段あるかのほうが、定着には効いてきます。
だからこそ、権限や承認の設計は現場の操作数の話と地続きです。

端末の条件も先に決めておく部分です。
会社から端末を貸与するのか、私物のスマートフォンを使ってもらうのか。
私物を使う場合は、通信費の扱いや、退職時にどうするかを決めておく必要があります。
冷蔵倉庫で手袋をしたまま操作する、暗い通路でバーコードを読むといった条件があるなら、そこも試用で確かめておきたい点です。

導入の進め方としては、まず1拠点で使ってみて、つまずいた箇所を書き出してから他拠点へ広げると、説明すべきことが具体的になります。
最初から全拠点に配って一斉に切り替えると、問い合わせが同時に来て、対応する側が回らなくなりがちです。

自社の拠点数・仕入先構成に応じた優先順位の付け方

拠点数が多い場合の優先軸

ここまでで、確認できた実装例と、各社へ個別に確認する4つの軸が出そろいました。
全部を同じ深さで調べると比較は進まないので、自社の条件から優先順位をつけます。
拠点数が多い場合、先に見たいのは課金と登録の単位です。
CO-NECTの発注側では、拠点ごとに管理を分ける事業者の登録数に制限や追加料金はないと記載されています²。
これは1社の記載であり、他社の課金単位が拠点数なのか、ユーザー数なのか、発注件数なのかは各社で異なります。
拠点を1つ増やしたとき、費用と設定作業がどれだけ増えるかを最初に押さえておくと、将来の拡張で詰まりません。

次に効くのが権限管理と承認フローです。
拠点が10、20と増えれば、発注を触る人の数もそれだけ増えます。
人数が増えるほど、誤った発注が出たときに誰の操作だったかを追えるか、確定の前に誰かが見る仕組みがあるかが、運用の安定に直結します。
逆に拠点が2、3で担当者の顔が全員見えているなら、承認を厚くするより、操作の簡単さを優先したほうが定着します。

展開の速さについては、公開されている事例に参考になる進め方があります。
化粧品部門の10店舗程度でのパイロット導入から本格導入へ進み、2か月で全国250店舗に拡大した例です⁴。
これは受注側の企業が取引先の店舗へ広げた記録であり、自社の多拠点導入にかかる期間を示す数値ではありません。
それでも、少数で試してから一気に広げるという順序は、自社の計画を立てるときの形として使えます。

仕入先・商品体系が拠点ごとに異なる場合の優先軸

拠点ごとに仕入先が違う、扱う商品が違う、同じ商品でも発注単位が違う。
この場合、最初の山は機能よりも初期設定です。
商品マスタ、発注単位、仕入先ごとの品番、単価の持ち方を、拠点の数だけ整えることになります。
拠点ごとに管理を分ける実装²を選ぶなら、登録そのものも拠点の数だけ発生します。

このとき先に数えておきたいのが、スキャンで拾える商品の割合です。
バーコードを読んで数量を入力する操作³が成り立つのは、商品にバーコードが振られていて、それが発注品番と対応している場合です。
拠点ごとに独自の資材や、仕入先の伝票でしか品番が分からない商品が多いなら、そこは手入力か、事前のマスタ整備で埋める部分になります。
割合が分かれば、初期設定にかかる手間の見当も具体的になります。

商品体系が拠点ごとに違う場合、既存システムとの連携の確認も前倒しになります。
拠点ごとに品番の体系が違えば、既存の在庫システムとの突き合わせも拠点の数だけ考えることになるためです。
逆に、全拠点が同じ仕入先から同じ商品を引いているなら、初期設定は一度整えれば横展開でき、優先したいのは権限や承認、オフライン時の動きといった運用側の軸になります。

どの軸から確認するかが決まったら、各社への問い合わせは同じ質問文で揃えるのが効率的です。
自社の役割分担、電波の悪い場所での動き、打ち直しをなくしたい画面の名前、拠点を増やしたときの費用。
この4点を同じ文面で送れば、返ってきた答えをそのまま横に並べて比べられます。
公開情報で差が見えない部分ほど、回答の具体性に製品の差が出ます。

拠点の分け方や現場の入力方法は公開情報から形が見えますが、権限管理・承認フロー・オフライン時の動き・既存システムとの連携は製品ごとに異なり、自社の運用に当てはめないと判断できない部分が残ります。

拠点数、仕入先の構成、いま手で打ち直している画面を挙げていただければ、どの軸を先に確認すべきか、各社へ同じ文面で送る質問をどう組み立てるかを一緒に整理できます。無料相談で要件を整理する

拠点管理・現場操作の確認できた実装例

各社の公式ページで記載を直接確認できた内容だけを、現場が触れる流れ（拠点の登録、利用者の登録、入力、履歴確認）に沿って並べています。

• 拠点ごとの管理：発注情報の管理を店舗ごとに分けたい場合は、事業者を複数登録して使い分ける。登録数の制限や追加料金はないと記載されている²

• 複数担当者での利用：複数のユーザーを登録すれば、それぞれの端末で同じ情報を閲覧・操作できる²

• 現場の入力：発注したい商品のバーコードをスマートフォンのカメラでスキャンし、数量を入力するだけで発注できる³

• 発注後の確認：スマートフォンとWebの両方で、いつでも発注履歴を確認できる³

先に決めたいのが拠点の分け方か、棚の前での入力方法かによって、確認に使う行が変わります。

要点の整理

軸	基準
移行の出発点	FAX・紙は判読と打ち直しの手間が生じやすい。まず自拠点のどの作業が紙に依存しているかを洗い出す
現場の操作	バーコードのスキャンと数量入力で発注できる製品がある。自社商品のバーコード付与率を先に数える
拠点の分け方	拠点ごとに事業者を分けて登録する実装例がある。分ける単位で履歴と発注先の見え方が変わる
個別確認の4軸	権限管理・承認フロー・オフライン対応・既存システム連携は製品ごとに異なるため各社へ同じ質問文で確認する
現場の年齢層	スマートフォンの利用率は高いが、発注アプリの習熟を示す数値ではない。覚える操作の数で判断する
優先順位	拠点数が多いなら課金単位と権限、仕入先や商品体系が違うなら初期設定と連携を先に確認する

製品を決めたあとも、拠点ごとの登録単位、権限の線引き、どの拠点から試すかという移行の順序は自社で設計する必要があり、ここでの決め方が稼働後の問い合わせ量を左右します。 現在の発注の流れと拠点ごとの違いを伺えば、試用で何を確かめるべきか、どの拠点から始めて何を見てから広げるかの進め方を具体化できます。

よくある質問

既存の在庫管理システムやPOSと連携できるかは、何を根拠に確認すればよいか

公開されている製品情報だけでは判断しないほうが確実です。
連携方式の一般的な選択肢として確定できる情報は確認できていないため、方式の名前から聞くより、いま人が手で入力している画面を具体的に挙げて確認します。
「発注を確定したあと、この登録画面への入力はなくなるか」「なくならない場合、どの形でデータを渡せるか」「渡したデータは誰がいつ取り込むか」「商品コードの対応表は必要か」を書面で回答してもらい、試用期間があれば自社の実データを1件通して、どこまで手作業が消えるかを確かめてください。

通信環境が悪い倉庫でも発注できるか、契約前に何を確認すべきか

オフライン時の動きは公開情報の範囲では確認できないため、製品ごとに個別に確かめる項目です。
対応の有無を一言で尋ねるのではなく、動きを具体的に聞きます。
圏外でスキャンして数量を入力した内容は消えるのか端末に残るのか、圏内に戻ったとき手動で送るのか自動で送られるのか、送信済みかどうかを画面で区別できるのか。
可能なら試用で、自社の一番電波の悪い場所（倉庫の奥、冷蔵庫内など）を実際に歩いて試すのが確実です。

拠点ごとに発注先や商品体系が違う場合、初期設定にはどの程度の手間がかかるか

期間を示す確認済みの情報はないため、自社の条件から見積もります。
数える対象は、商品点数、バーコードが振られている商品の割合、仕入先の数、拠点ごとに異なる発注単位や単価の有無です。
拠点ごとに発注情報の管理を分ける実装を選ぶ場合は、登録そのものが拠点の数だけ発生します²。
バーコードのない商品が多いほど、スキャンでは拾えず事前のマスタ整備が必要な部分が増えるため、この割合が手間の大きさをおおよそ左右します。

導入後、現場が操作に慣れるまでにどの程度の教育期間を見ておけばよいか

期間を示す確認済みの数値はありません。
覚える操作の数で見当をつけるほうが現実的で、バーコードのスキャンと数量入力³だけなら手順は少なく、ログイン、拠点の切り替え、承認待ちの確認が加わるほど増えます。
展開の進め方としては、パイロット導入（10店舗程度）から本格導入へ進み、2か月で全国250店舗へ拡大した事例があります⁴。
これは受注側の企業が取引先店舗へ広げた記録で、習熟期間を示す数値ではありませんが、まず少数の拠点で試し、つまずいた箇所を整理してから広げる順序は参考になります。

1. 1　出典：総務省「令和7年版 情報通信白書 インターネット接続端末」（2025年）
2. 2　出典：CO-NECT株式会社「受発注システムCO-NECT｜発注側 公式ページ」（2026年・確認時点の公開版）
3. 3　出典：ユーザックシステム株式会社「Pittaly Order 公式サービスページ」（2026年・確認時点の公開版）
4. 4　出典：ユーザックシステム株式会社「Pittaly Order 導入事例（花王グループカスタマーマーケティング株式会社）」（2026年・確認時点の公開版）