各レジを編集せずに、すべての店舗に価格変更を一元反映させるには？
価格変更のためにすべてのレジを編集する必要があるなら、価格はカタログではなくハードウェアに存在しています。レジごとのプライスブックが破綻する理由、有効な回避策、そして1回の中央編集ですべての店舗に反映させる仕組みについて解説します。
Mathias NielsenCEO, Final POS
すべての店舗に価格変更を反映させるには、一元化された1つのカタログで変更を1回行い、すべてのレジにそこから読み込ませます。答えはそれだけです。もしお使いのシステムで、各レジまで歩いていったり、6つのバックオフィスにリモート接続したり、USBメモリからファイルを読み込んだりする必要があるなら、価格は実際の価格表ではなくハードウェアの中に存在しています。書籍や端末の中に存在する価格は、そのハードウェアがある場所ごとに変更しなければなりません。
なぜ価格変更のために各レジを編集する必要があるのか？
それは、古いPOSシステムが各レジを個別の小さなデータベースとして扱うためです。端末はローカルのプライスブック（レジに保存された商品と価格のリスト）を保持し、会計時にはそのローカルコピーから読み込みます。本部が完璧なマスターのスプレッドシートを管理していても、レジはその存在を知りません。レジが「信頼できる唯一の情報源」（誰もが実際に信頼するデータ）となっている場合、すべてのレジに個別で変更を通知しなければなりません。
レジがオフラインの機器であり、通信環境が贅沢品だった時代には、その設計にも理がありました。何年も前にそれは時代遅れになりましたが、このデータモデルは多くの導入型システムや、それを踏襲した一部の新しいシステムに残り続けています。その結果、レポート機能の代わりに行われる毎晩のCSVエクスポートと同じパターンが発生します。つまり、データが存在する場所の都合を補うために、スタッフが恒常的な手動ルーチン作業を実行させられるのです。
レジごとの価格編集には実際どれほどのコストがかかるのか？
費やされる夜の時間以上のコストがかかります。予期される失敗パターンは以下の通りです。
店舗間でのデータのズレ（ドリフト）。3月に1台のレジの更新を漏らしたことで、同じSKU（固有の商品コード）がオフィス街の店舗とショッピングモール内の店舗で異なる価格でスキャンされてしまいます。顧客に指摘されるまで誰も気づきません。在庫記録はただでさえ自然とズレていくものですが、手入力でコピーされた価格はさらに早くズレていきます。
更新漏れの端末。更新処理中に会計中だったり、電源が切られていたり、単に忘れられていたレジは古いプライスブックを保持し続け、何週間も平然と古い価格で会計を行ってしまいます。
値札とレシートの不一致。手動での編集作業を行うたびに、スキャンされた価格と棚の値札が一致しなくなる新たなリスクが生じます。そして不一致に気づいた顧客は、店内の他のすべての価格に対する信頼を少し失うことになります。
あいまいなレポート。同じ週に1つの商品が3つの異なる価格で販売されると、粗利レポートは意味をなさなくなり、消込作業（レポートの数字と実際に動いた金額を照合すること）は発掘調査のような大変な作業になります。
時間外労働。レジごとの編集作業は閉店を待って行われるため、残業代が発生するか、あるいは作業が後回しになります。仕入原価がすでに上がっている場合、作業を待つ毎日は粗利益をそのままドブに捨てているようなものです。
レジごとのシステムで有効な回避策とは？
現在レジごとの価格設定システムから抜け出せない場合でも、失敗を最小限に抑えるルーチンがあります。
バッチ処理を行い、手入力を避ける。1つのマスター価格ファイルを保持し、端末ごとに作業する必要がある場合でも、システムの出入力（エクスポート/インポート）ツールを使って読み込みます。キーパッドで数字を打ち直す作業こそがエラーの温床となります。
マスターレジを指定する。1台のレジの設定を他のレジにコピーできるシステムの場合、1台の端末をソースにして複製します。完全な同期ではなくても、何もしないよりははるかに優れています。
変更の実施プロセスを厳格に管理する。担当者は1人、日付付きのマスターファイルは1つ、全端末を網羅したチェックリストを1つ用意します。データのズレのほとんどは「レジ2はあなたが更新したと思っていた」という勘違いから生じます。
目視ではなくスキャンで確認する。更新後、各店舗で変更した商品をいくつかテスト販売（スキャン）してみます。設定画面には新しい価格が表示されていても、レジ会計では古い価格が請求されることがあるためです。
価格変更ログを残す。後からデータのズレが発覚した際、日付入りのログがあれば、推測ではなく正確な原因特定が可能になります。
これが何であるかについて素直に捉えましょう。これは「設計上の欠陥に対するメンテナンス」です。これは非課税の購入者ごとに手作業で税金を削除することと同じカテゴリーであり、データモデルが一度で処理すべきだったことを人間が延々と手作業で行っている状態です。
本来、価格変更はどのように機能すべきか？
価格はクラウド上の一元化されたカタログという、ただ1つの場所に存在するべきです。そして各レジは、自身のコピーを保持する所有者ではなく、そのカタログのクライアントとして機能します。商品レコードを変更すれば、他に価格を保持している場所がないため、配信（プッシュ）する作業自体が不要になります。これこそが、従来の設置型システムに対してクラウド型システムを推奨する根本的な理由であり、すべてのビジネスのためのPOSシステム：あなたに最適なタイプは？でも解説しています。
Final POSでは、カタログはこのように構築されています。商品はマーチャントハブ内の1つの商品リストに存在し、価格は商品レコード上の1つの項目であり、アウトレット（店舗拠点）が各商品がどこで販売されるかを管理します。全アウトレットのすべてのステーションが同じレコードを読み込むため、価格を1回編集するだけで作業はすべて完了します。
率直な注意点が2つあります。レジが更新を受け取るにはオンライン状態である必要があるため、確認手順は「数値の再入力」ではなく「端末が接続されていることの確認」へと削減されます。また、意図的に店舗ごとに異なる価格を設定する場合、それは手動でレジのデータをズレさせることで再現するのではなく、ルールとしてカタログ側に組み込むべき価格設定の判断となります。
では、各レジを編集せずにすべての店舗に価格変更を一元反映させるには？
レジごとのシステムを使用している場合、それは不可能です。システム上の限界があるため、変更をバッチ処理し、可能な場合は複製し、テストスキャンで確認するしかありません。一方、一元化されたカタログを持つシステムでは、商品を1回編集するだけで完了します。判断の基準はこうです。「価格の変更にハードウェアを操作する必要があるなら、カタログがレジを管理しているのではなく、レジがカタログを管理してしまっている」。新しいシステムを検討している場合は、デモのシナリオに「1つの価格を変更して全レジに即座に反映されるか見せてほしい」という項目を加え、導入が決まったら最初の1週間のセットアップチェックリストに沿って進めてください。
よくある質問
POSレジにおけるプライスブックとは何ですか？
レジ内部にローカル保存されている商品と価格のリストであり、会計時にそこからデータが読み込まれます。古いPOSシステムでは各端末がそれぞれのコピーを保持しているため、価格変更をすべてのレジで繰り返す必要があります。
なぜ同じ商品なのに店舗によって価格が異なるのですか？
各レジが独自の価格データを保持しており、いずれかの端末で更新漏れが発生したためです。手入力でコピーされた価格は手計算の在庫と同様に不整合が生じやすくなりますが、一元化されたカタログを導入すれば不整合の原因となるコピー自体が不要になります。
価格変更がすべてのレジに反映されたか確認するにはどうすればよいですか？
各店舗で変更した商品をいくつかテスト販売（スキャン）してみます。設定画面には新しい価格が表示されていてもレジ会計では古い価格が請求されることがあるため、設定画面ではなく実際に発行されるレシートを確認してください。
意図的に店舗ごとに異なる価格を設定することはできますか？
店舗ごとに価格を変える運用を行う企業もありますが、これは端末ごとの手動編集ではなく、カタログや価格設定のルールとして定義されるべきです。運用を開始する前に、お使いのシステムが店舗別価格設定をどのように処理するか確認してください。
クラウドPOSはすべての店舗で即座に価格を更新しますか？
変更は共有カタログに即座に適用されます。オフラインだったレジは再接続時に更新を取り込むため、手作業で数値を再入力する代わりに、各端末がオンラインであるかを確認するだけで済みます。